In the SCRUM approach clearly requires that the three documents:
1 product backlog
2sprint backlog
3 burn-down chart
Product backlog listed the needs of the project should be implemented, the demand for the use of a user story the way described, the user is a short story using familiar terminology to express the needs of the user story to tell developers, not the developers say to the user story. Since it is a story, someone will say, who to say it is the product owner is concerned, may have different details, there should be changes each time you speak, but the original aim, so the story itself is a certain degree of flexibility of. The story may have a standard format, I call syllogism story, which three sections of it?
1 user roles
2 functionality required
Objective 3
For example, there is such a story:
As a housewife, I need a 30-square-meter restaurant, so you can entertain in my 10 friends to dine.
User roles are housewives, 30-square-meter restaurant is functional requirements, entertain 10 friends dining is why you need this feature. Do not underestimate this syllogism story, we need to carefully pondering the role of each segment. User roles indicate who use this feature, if a user function is not clear, whether you can delete it? If a user role is not important whether the low priority that needs it? The purpose explains why you need this feature, which solved the problem, if a function is not clear purpose, whether it can remove it? If the purpose is not critical, whether this demand can be of low priority to it?
priority? Yes, I have repeatedly referred to the priority needs must be prioritized! Who divided the priority needs? Product owner! How to prioritize? According to the commercial value! According to customers, the commercial value of the end-user to prioritize. How to distinguish the size of the commercial value of it? For example, ask questions if you do not achieve this requirement, if late implement this requirement if the customer is not satisfied with, what kind of people are dissatisfied? Not satisfied to what extent? Some experts also proposed a more professional approach, in fact, not necessary, if the product owner is really competent, I believe he can be empirically divided into priority.
If only such a word to describe the full of it? In fact, there fourth paragraph, that user acceptance criteria story or user stories called test points, which is the product owner to complete, the product owner can be completed in the first three segments, and team member of the communication process, step by step rich sound acceptance criteria. For that story we mentioned earlier, if you implement such a restaurant, for example, is a 2-meter-wide, 15-meter restaurant, how housewives who would want to? Haha, if her mental health, it is estimated she quickly let you jump off! If her mental unhealthy, she would jump off. Of course, this phenomenon does not occur in agile methods, in the course of your development, the product owner will communicate with you at any time, and in the communication product owner also conveyed this message:
1 I hope this restaurant is five meters * 6 meters;
2 I hope this restaurant is bright;
3 I hope this restaurant near the kitchen;
4 ......
This is the acceptance criteria! May be a different perspective, to describe how the terms of acceptance:
1 I will if the amount of this room is five meters * 6 meters;
2 Cece if I would play poker in this room during the day, do not turn on the lights, then, you can see poker suit and points;
Cece 3 I would need to go from the kitchen to the dining room a few steps;
4 ......
If a story does not mention the acceptance criteria out how to do it? Do not realize it, realize it late, until a clear acceptance criteria.
So far we actually talked about in containing the product backlog in 5 sections:
Product backlog = demand + priority
= User Story + priority + acceptance criteria
User Role = + Function + purpose + priority + acceptance criteria
Some experts singled out the acceptance criteria, I believe that the acceptance criteria are part of the requirements, but for a way to describe it, so it is still a part of product backlog it.
As I have been mentioning "functional" word, not to mention non-functional requirements, and if there is non-functional requirements of how to do? Two approaches, one can clearly if to a story, acceptance criteria described in the story, the second is to write a "technology story," singled out, to remind developers to pay attention to these stories, the story may not be the product owner made of.
For user stories we hope to achieve the following ideals:
1) independence. Try to avoid dependencies between stories, there is a dependency between the story will result in prioritizing difficulties, in order to be considered when developing arrangements dependencies between stories.
2) can be negotiated. The story is negotiable, the story is elastic, the story is the need to say, a written contract or demand is not to be achieved.
3) the user or customer valuable. The best way to ensure that each customer or user story valuable is to allow users to write stories.
4) predictability. Developers should be able to predict (at least approximate guess) time scale of the story, as well as achieve the required encoding.
5) short and pithy. Generally a story in an iterative cycle must be achievable, and we advocate short-cycle iteration.
6) testability. Written story must be testable, you can define acceptance criteria.
Note that this is ideal!
Product backlog will change in the course of progress of the project, only the product owner has the right to modify this document. You can use the EXCEL file to describe it, a number of agile project management tools can also be used to help you maintain, or use some drawbacks, such as tracking tools , the most intuitive of the most simple way is to use JIRA like quit stickers, direct posted on the board office at any time so that everyone can see!