- 1 Introduction
- 2 Installation
- 2.1 Choose the Right Installation
- 2.2 ZenTao Cloud
- 2.3 One-click Installation for Windows
- 2.4 One-click Installation for Linux
- 2.5 Installation with Lampp
- 2.6 Source Code Installation (for all systems)
- 2.7 Source Code Installation for macOS
- 2.8 XAMPP-VM Installation for macOS
- 2.9 XAMPP Installation for macOS
- 2.10 Docker installation
- 2.11 Softaculous Service
- 2.12 Integrate Zdoo
- 2.13 Install Ioncube
- 3 Update
- 3.1 Update ZenTao
- 3.2 Update by Source Code (for all systems)
- 3.3 Update for One-Click Installation for Windows (xampp)
- 3.4 Update for One-Click Installation for Linux
- 4 Users and Groups
- 5 Quick Start
- 6 Basic Application
- 6.1 Basic Workflow
- 6.2 Agile and Scrum
- 6.3 ZenTao and Scrum
- 6.4 ZenTao Tutorial for Rookies
- 6.5 Create a Product
- 6.6 Create a Story
- 6.7 Create a Project
- 6.8 Confirm a Story
- 6.9 Decompose Stories into Tasks
- 6.10 Report a Bug
- 6.11 Manage Contacts
- 6.12 Customization
- 6.13 Import Excel, CSV Files
- 6.14 Document Management
- 6.15 Work Mode
- 6.16 Points
- 6.17 Required Field
- 6.18 Privileges
- 6.19 Annual Work Summary
- 7 Advanced Application
- 7.1 Workflow
- 7.1.1 ZenTao Workflow
- 7.2 Individual management
- 7.3 For Product Owner
- 7.3.1 Manage a Product
- 7.3.2 Manage a Product Line
- 7.3.3 Create and Review a Story
- 7.3.4 Change and Review a Story
- 7.3.5 Status and Phase
- 7.3.6 Story Writing
- 7.3.7 Product Module
- 7.3.8 Release Plan
- 7.3.9 Create a Release
- 7.3.10 Roadmap
- 7.3.11 Documents
- 7.3.12 Planning Meetings
- 7.3.13 Daily Scrum, Review and Retrospective Meetings
- 7.3.14 Story Reports
- 7.4 For Project Manager
- 7.4.1 Create a Project
- 7.4.2 Set up a Team
- 7.4.3 Confirm a Story
- 7.4.4 Task Breakdown
- 7.4.5 Daily Standup Meetings
- 7.4.6 Check Project Progress via Burndown Chart
- 7.4.7 Check Project Progress via Lists
- 7.4.8 Review and Retrospective Meetings
- 7.4.9 Basic reports on tasks
- 7.5 For Development Team
- 7.5.1 Project planning meeting and task breakdown
- 7.5.2 Claim tasks and update efforts
- 7.5.3 Kanban and Tree Diagram
- 7.5.4 Build
- 7.5.5 Test Request
- 7.5.6 Resolve a Bug
- 7.5.7 Documents
- 7.5.8 Confirm Bugs
- 7.6 For QA Team
- 8 Configuration
- 8.1 Maintain ZenTao
- 8.1.1 Initialize scripts
- 8.1.2 Data Backup
- 8.1.3 Recover the Deleted
- 8.1.4 Update Burndown Charts
- 8.1.5 ZenTao Remote Host
- 8.2 Deploy ZenTao
- 8.2.1 Guest Login
- 8.2.2 Email Notification
- 8.2.3 Set Super Admin
- 8.2.4 Static Access
- 8.2.5 Remove "zentao" from URL
- 8.2.6 Integrate SVN
- 8.2.7 Integrate Git
- 8.2.8 Integrate Webhook
- 8.2.9 Integrate Xuan.im
- 8.2.10 Integrate Zdoo
- 8.2.11 Integrate Third-Party Apps
- 8.2.12 Password-Free Login
- 8.2.13 Translation Add-on
- 8.2.14 Integrate Jenkins
- 8.2.15 Extension
- 9 Customization
- 9.1 Introduction
- 9.2 Directory
- 9.3 Find Codes
- 9.4 Database Structure
- 9.5 Common Modules
- 9.6 Add Features to Menu
- 9.7 Set Privileges to Modules
- 9.8 Examples: modify language prompt
- 9.9 Examples: set priority when creating bugs
- 9.10 Extension Editor
- 9.11 Feature Limitation
- 9.12 ZenTao Packaging Standards 1.1
- 10 Misc
1. Writing stories in ZenTao
In ZenTao, a default story template is offered to all users, which is,
As a < type of user >, I want < some goal > so that < some reason >.
This template is based on user story writing in Scrum development, but we adopt a relatively neutral concept.
In this template, there are three factors, roles, goals, and reasons. Usually, roles and reasons tend to be ignored, while goals have been paid much attention to. It will cause some problems. If roles are not defined, the design and positioning of product functions will be affected. Consequently, this product will be developed for just one user role, which is for the product manager who wrote stories. Besides, developers will get confused, if the development reasons are ignored. They would not understand why they are asked to do it, and thus it will be difficult for them to finish stories.
2. INVEST principle for stories
Except for the template mentioned above, you can also refer to the INVEST principle when writing a story. Refer to https://en.wikipedia.org/wiki/INVEST_ (mnemonic) for more about the INVEST principle.
I —— Independent
A user story should be independent of the other user story. The interdependent stories would make it quite difficult to do planning, prioritizing and estimation. Dependency can be reduced through story combination/subdivision.
N —— Negotiable
A user story should be negotiable. A story card should contain a brief introduction of the story, which is defined through meetings and discussions. A card which contains much information actually reduces the talking with clients.
V —— Valuable
Each user story must be valuable for clients (both the customers and the users). One way to make user stories valuable is to let the clients write them. Once clients realize that a user story is not contractual but negotiable, they will be very willing to write them.
E —— Estimable
Developers need to estimate the user story in order to set priorities and make plans. But what makes it difficult for developers to estimate is the lack of relevant knowledge in certain industry, which could be solved by more communication; or because the story is too big, and should be subdivided.
S —— Small
A great user story should be small in terms of workload and description, and it could be done by two/three persons. User stories bigger than the workload of 2-3 persons will cause problems when subdivided and estimated.
User stories are testable and can be finished through testing. Remember, stories that are not testable should not be developed. If you cannot test the stories, you will never know when they can be finished. An example of untestable user story is that software should be user-friendly.
A well-written user story is the basis of Agile development. The stories should be independent of each other and convenient for communication between developers and users. At the same time, they should be valuable for users and as small and clear as possible for developers to estimate, as well as testable.
3. Differences between a Story, a Prototyping Model and a Story Design Document in ZenTaoIn traditional project management, many product managers use software to design a prototype or a complete story design document. Then the prototyping model or document is sent to designers for web design and then to developers for coding. So what are the relations and differences between prototyping models and user stories?
- Compared with user stories, prototyping models or story design documents are considered as one unity and understood at a macro level. This is very intuitive, which is also the advantage of prototyping models.
- Since it is one unity, it cannot be divided into a navigation bar or the middle of a page, etc.
- Since it cannot be subdivided, priorities cannot be set in prototyping models. For example, some parts of a page are important while others are not, the priorities of which cannot be displayed in prototyping models.
- Since it cannot be subdivided, you cannot track the progress in prototyping models. Consequently, you don't know how much has been completed.
- Prototyping models are not flexible, which make it difficult for designers and developers to change. What they can do is to passively implement prototypes.
- Story design documents are usually very specific, which also make product managers caught up in details and reduce overall management.
Although there are some shortcomings in traditional management, prototyping models or story design documents can be the supplement for each other in actual development. Document library management has been added in ZenTao 1.2. The prototyping models can be used as design documents to be uploaded to a document library, and integrated with user stories.