- 1 Introduction
- 1.1 About ZenTao
- 1.2 How to get support
- 2 How to Install ZenTao
- 2.1 Choose the best installation
- 2.2 ZenTao Cloud
- 2.3 One-click Installation Package for Windows (Recommended)
- 2.4 One-click Installation Package for Linux
- 2.5 Source Code Installation Package (for all Systems)
- 2.6 Set up Virtualbox for ZenTao
- 2.7 Softaculous service
- 3 Upgrade ZenTao
- 3.1 Choose Upgrade
- 3.2 Upgrade by source codes (General for all systems)
- 3.3 Upgrade for one-click installation package for windows users (xampp)
- 3.4 Upgrade for one-click installation package for Linux
- 4 Users and Groups
- 5 Simple Application
- 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 Stories
- 6.9 Decompose Tasks
- 6.10 Report a Bug
- 6.11 Manage Contacts
- 6.12 Customization
- 7 Advanced Application
- 7.1 Workflow
- 7.1.1 ZenTao Workflow
- 7.2 Personal management
- 7.2.1 My To-dos
- 7.2.2 My Task, Story and Bug
- 7.2.3 My Profile
- 7.3 Product Manager
- 7.3.1 Manage a Product
- 7.3.2 Create and Review a Story
- 7.3.3 Change and Review a Story
- 7.3.4 Story Status
- 7.3.5 Notes for Writing a Story
- 7.3.6 Product Module
- 7.3.7 Release Plan
- 7.3.8 Create a Release
- 7.3.9 Roadmap
- 7.3.10 Manage Documents
- 7.3.11 Product Meetings
- 7.3.12 Project Management, Presentation and Summary
- 7.3.13 Story Reports
- 7.4 Project Manager
- 7.5 Development Team
- 7.5.1 Project planning meeting and decompose tasks
- 7.5.2 Claim and update Tasks
- 7.5.3 Create a Build
- 7.5.4 Test Task
- 7.5.5 Resolve a Bug
- 7.5.6 Manage Documents
- 7.5.7 Confirm Bugs
- 7.6 Testing Team
- 7.6.1 Bug Management
- 7.6.2 Submit a Bug
- 7.6.3 Confim and Close a Bug
- 7.6.4 Activate a Bug
- 7.6.5 Find a Bug
- 7.6.6 Test Case
- 7.6.7 Create a Test Case
- 7.6.8 Manage a Test Task
- 7.6.9 Execute Cases and Report Bugs
- 7.6.10 Reports
- 8 Configuration
- 8.1 Maintain ZenTao
- 8.1.1 Initialize scripts
- 8.1.2 Back up ZenTao
- 8.1.3 Recover the deleted
- 8.1.4 Update Burndown charts
- 8.2 Deploy ZenTao
- 8.2.1 Guest Login
- 8.2.2 Cnfigure Email
- 8.2.3 Set Super Admin
- 8.2.4 Configure Static Access
- 8.2.5 Delete "zentao" from your address
- 8.2.6 Integrate ZenTao with SVN
- 8.2.7 Integrate ZenTao with Git
- 9 Custom Development
- 9.1 ZenTao Mechanism of Developing
- 9.2 ZenTao Directory
- 9.3 Modify files
- 9.4 ZenTao Database
- 9.5 Common Modules
- 9.6 Add features to navigation bar
- 9.7 Examples: Modify Language Prompt
- 9.8 Examples: set priority when creating bugs
- 9.9 Web Editor
- 9.10 Packaging Standards of ZenTao 1.1
- 10 Other Relevant Issues
- 10.1 About third-party code
- 10.2 ZenTao FAQ
- 10.3 How to Help ZenTao
- 10.4 ZenTao Business Service
- 10.5 Acknowledgement
Notes for Writing a Story
- 2015-09-11 10:10:22
- Last edited by xiying guan on 2018-12-06 10:09:40
1. Writing stories in ZenTao
In ZenTao, a default story template is offered to all users, which is,
"As a (Type) user, I want to do (achievement), so to realize (the values of development) .
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, which are roles, things to be done and values/reasons. Usually roles and values/reasons are ignored when we are writing a story. Only things to be done are being paid much attention to. This 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, the product manager who wrote stories. Besides, developers will get confused, if the development reasons/values are neglected. They may not understand why you asked them to do this, and thus it will be difficult to finish stories.
2. INVEST principle for storiesExcept for the template mentioned above, you can also refer to the INVEST principle (Reference http://duweizhong.blogbus.com/logs/112151436.html) when writing a story.
I —— Independent A user story should be independent from the other user story. The interdepent stories would make it quite difficult to do planning, priorities and estimation. Dependency can be reduced through story combination/subdivision.
N —— Negotiable: 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 conversations 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 writie 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 user stories is the lack of relavant knowledge in certain industry, which could be sovled by more communication, or that the story is too grand, which could be sovled by subdividing the story.
S —— Small: A good user story should be small in terms of workload and description and could be finished by two/three persons. User stories bigger than that will cause problems when subdivided and estimated.
T—— Testable: User stories are testable and can be finished through testing. Remember, we don’t develop stories that are not testable. If you can not 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 for agile development. The stories should be independent from 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 stories, prototypes and story design documents in ZenTaoIn traditional project management, many product managers use software to design a prototype model or a complete story document. Then the prototype modle or documents is sent to designers for web design and then to developers for code merging. So what are the relations and differences between prototype models and user stories?
- Compared with user stories, prototype models or story designs are considered as one unity and understood at a macro level. This is very intuitive, which is the advantage of prototype 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 subdivded, priorities cannot be set in prototype models. For example, some parts of a page are important while others are not, the priorities of which can not be presented in prototype models.
- Since it cannot be subdivded, you can not track the progresses in prototype models. Consequently, you can’t get to know how much has been completed.
- Prototype models are not flexible, which make 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, prototype models or story design documents can be supplement for each other in actual development. Document library management has been added in ZenTao 1.2. The prototype models can be used as design documents to be uploaded to a document library, and integrated with user stories.