[agile 5.1] core of planning: user stories

Core of planning ： A user story

As soon as you see the title , Do you feel excited immediately , After talking about agile framework , I guess the most exciting part is today's article . User stories , It is now a common tool for describing requirements in agile . When it comes to agility , You have to ask the user stories . What we learned before To do list , Iteration sprint list Something like that , All recorded are user stories . In the sprint , Whiteboard 、 Posted on the task board , It's all user stories . that , Do you know how to write a real user story ？

User story format

A user story （User Story） It describes the functions that users desire from the perspective of users . A good user story should include 3 Elements ：

1. role ： Who wants to use this feature

2. Activities ： What functions need to be completed

3. Commercial value ： Why do you need this function , What value does this feature bring

Through this 3 Elements , We can summarize a standard format of user stories ：

As a ｛ role ｝, I want ｛ Activities ｝, For convenience ｛ Commercial value ｝.

For example, let's take an example ： As a “ Workers ”, I hope “ Can easily buy train tickets ”, For convenience “ Don't queue up at the railway station in cold weather ”. Through this user story ,12306 The birth of .

Of course , The scope of this story is actually a little big , How to buy tickets 、 How to choose a seat 、 How to line up online and so on can be refined into more detailed stories . We also call this very wide-ranging story epic Epic . Such a story is not a good story , The following story may be relatively better .

As “ Operation of the company ”, I want “ See the number of newly registered users ”, For convenience “ Statistical product innovation effect ”.

It should be noted that , Try not to use technical language to describe user stories , The above story has some biased Technology . We should try to describe what to do in the form of a story from the perspective of customers and interested parties . The technical language is what happens after the user story is assigned and split into tasks in the iteration . Of course , This kind of user story proposed by internal employees of the company is still acceptable , After all, these data are not special technical terms .

General user stories are written on a card , Also known as User story card . For this User story card , There is such a 3C principle .

• CARD（ card ）： Write it on the card , Facilitate recording and discussion , It is also convenient to move on the task board .

• CONVERSATION（ conversation ）： The details behind the user story , It should come from discussion sessions with customers and various interested parties .

• CONFIRMATION（ confirm ）： Use acceptance tests to convey and record the details of the story and decide when the story is officially completed .

INVEST principle

above 3C The principle can be seen as User story card Production principle of , However, it also implies the compilation principle of user stories . however , Without these six features A user story , It's definitely not a good A user story , Many people will call these six principles A user story The basic principles of . The initials of these six principles are INVEST The word , What's interesting is , This INVEST The Chinese meaning is to invest . User stories really need to be established and determined by us, the team and relevant personnel with full commitment .

independent （Independent）

User stories should be independent , How do you understand that ？ There is no interdependence between user stories . If there are dependencies between user stories , Then the dependent user stories have natural priorities . Of course , There is really no way to avoid this thing , It's like we're going to develop the integration function , That must be to develop the user center function first , User development center , Then you must have a login first , When the user table is not determined , Then the functions related to users may not be realized .

So there's no way to solve this problem ？ It can only be said , We should try our best to dismantle small user stories , Then try to reduce the dependence of user stories in this release within a release cycle .

Negotiability （Negotiable）

User stories are not like signed contracts , Once signed, it will remain unchanged , It's just a description of user needs , It doesn't contain too many details . therefore , User stories should be negotiable , If too many restrictions are defined at the beginning , Then there will be no better communication and negotiation . Because the details and limitations should be determined in the development stage , Only after the user story is broken down into tasks . meanwhile , The negotiation that developers can participate in can also make user stories get more developers' approval and support .

valuable （Valuable）

In fact, there is no need to say more about the word value . Several articles have been discussed on the issue of value before . If the user story has no value , What are we delivering ？ It's said that delivery should be driven by user value . The best solution is to let users write their own user stories , If it's not convenient , Then the user agent or PO You should also try to write from the perspective of users . The average user knows that the user story is not a definite document to-do , Nor is it in the case of contractual constraints , Will be very willing to try to write their own user stories .

Estimable （Estimable）

Generally speaking , The bigger the story, the less estimable , For example, the epic story we mentioned above . It seems very simple , Can buy train tickets online , So you know 12306 How many times have you changed the version , How many ways have we thought about so that we can buy train tickets more smoothly now ？ It's a bit like a joke , Party A said that the demand is very simple , Just be a Taobao . This kind of thing , In fact, it's really too empty , There's no way to estimate , So it's still the plan , Split , Split step by step , It has to be small enough , And it allows developers to complete it in one iteration . in addition , Domain knowledge is also important for estimation , Without the foreshadowing of domain knowledge , The estimation gap may also be very large . Agile doesn't pay attention to accurate estimation , But the kind with a difference of 18000 miles is also unacceptable .

Small （Small）

see , I'll start talking about this little thing right away . A good story must be as short as possible in workload , The problem of estimation error has been mentioned earlier , The smaller the story, the more accurate the estimation is , And it should also be able to complete in an iterative sprint cycle , This completion refers to the one agreed upon after the test is passed “ complete ”. Of course , It's not a good thing to be too small , A trivial list of stories can cause a lot of trouble for maintenance . For example, change the color of a button on the page , Change a word , Such needs should be combined into a story of the right size .

Testable （Testable）

This feature is very important for user stories . Why? ？ We just talked about “ complete ” The problem of . Testing is to check whether “ complete ” A standard of . in addition , User stories also provide the basis for test cases , And when dividing tasks , We should also take the passing rate of unit test cases as the standard to measure the completion of tasks . therefore , It's about how our story ends . For example, a user story is that the system should be easy to use , Easy to use, this thing can't be tested , At the same time, it can't be estimated .

summary

User stories , There is a very famous book , And it's also PMI-ACP Ranked first in the exam recommended learning materials , It is a necessary book for exams , That's it XP founder Kent Beck The great god 《 User stories and agile methods 》. Whether you are taking an exam or learning to understand , This book is a highly recommended introduction to agile . Today's article doesn't actually write too many examples of user stories , The main reason is actually that we don't have much experience , I've brought an agile team before , And the interval is long . But there are many in this book , A very good example , I really recommend you to buy it and have a look .

Reference documents ：

《 Teaching materials of a training institution 》

《 User stories and agile methods 》

《 Efficiently pass PMI-ACP The test （ The first 2 edition ）》

《 Agile project management and PMI-ACP Exam Guide 》