1. How to describe Stories in ZenTao

In ZenTao, we provide a default story template for all users, which is,

As a < type of user >, I want < some goal > so that < some reason >.

This template is based on user story template in Scrum Guide, 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.

T—— Testable

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 Stories, Prototypes and product design requirement documents (PRD) in ZenTao

In traditional project management, many product managers use software to design a prototype or a complete the PRD. Then the prototypes or documents will be sent to designers for web design and then to developers for coding. So what are the relations and differences between prototypes and user stories?

• Compared with user stories, prototypes or the PRD are considered as one unity and understood at a macro level. This is very intuitive, which is also the advantage of prototypes.
• 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 prototypes. For example, some parts of a page are important while others are not, the priorities of which cannot be displayed in prototypes.
• Since it cannot be subdivided, you cannot track the progress in prototypes. Consequently, you don't know how much has been completed.
• Prototypes are not flexible, which make it difficult for designers and developers to change. What they can do is to passively implement prototypes.
• The PRD is usually very specific, which also makes product managers caught up in details and reduce overall management.

Although there are some shortcomings in traditional management, prototypes or PRD can be the supplement for each other in actual development. Document library management has been added in ZenTao 1.2. The prototypes can be used as design documents to be uploaded to a document library, and integrated with user stories.