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 stories

Except 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 ZenTao

In 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.