User story invest principles

User story invest principles -[Estimating and planning-back]

Copyright statement: Reprinted with a hyperlinkArticleSource and author information and this statement
Http://duweizhong.blogbus.com/logs/112151436.html

Invest description:
IDependent (independent): A User story should be independent (as far as possible) for another user story ). The dependence between stories makes it very difficult to estimate plans and establish a limited level. In general, you can reduce dependencies by combining user stories or splitting user stories.

 

NEgotiable: A User story is easy to communicate. A story card contains a brief description of the story details. These details are completed through the discussion phase. A card with many details actually reduces the number of talks with customers.

 

VAluable (valuable): Each story must be of value to the customer (whether the user or the buyer ). A good way to make user stories valuable is to let customers write them down. Once a customer realizes that a user story is not a contract and can negotiate, they will be very happy to write the story.

 

EStimable: developers need to estimate a user story to determine a limited level and plan the story. However, it is difficult for developers to estimate the cause of the story: lack of domain knowledge (in this case, more communication is required ), or the story is too big (in this case, you need to split the story into smaller ones ).

 

SMall (short): A good story should be short in terms of workload and representative description, with a workload of no more than 2-3 people per week. There will be many errors in the scope and estimation of user stories beyond this range.

 

TEstable (testable): A User story can be tested to confirm completion. Remember, we do not develop a story that cannot be tested. If you cannot test it, you will never know when it will be finished. An untestable user story example: software should be easy to use.

Compiling a good user story is the foundation of agile development. They should be independent from each other. Details should be easy for developers to communicate with users. They should be valuable to users and should be as clear as possible for developers for estimation, you can use a predefined test case to make sure that it can be tested.