As an Agile Coach, one of the imperative items that I spend time with every team is on perfecting the art of crafting User stories. But wait … what is a User Story ?
A User story is documentation that tells you three things about requirement(s): Who, What, and Why. This enhances communication among the stakeholders and enables work estimations by the team. For example, as a grocery company launching an online portal for customers to place orders, you would need specific features to be delivered for your online portal. Each such feature is identified as a User Story. While one user story shall describe User Registration, the other might talk about User Login, User adding items to cart and finally Users checking out.
The general format of a User story is: As a <User Profile> I want <Feature description> so that <business value>.
As simple as it sounds, getting a user story right is an Art more than science where the product owner (or) analyst needs to juggle both business requirements with technical limitations. My agile handbook has a bookmark to handle this item and it reveals the chapter on Bill Wake succinct response.
User Stories need to be:
- I – Independent
- N – Negotiable
- V – Valuable
- E – Estimable
- S – Small
- T – Testable
- Independent: Each User Story should be independent of one another, else they cause trouble during estimation and prioritization.
- Negotiable: A User Story should leave opportunities for conversation or negotiation with the customer. A story card should contain a short description without too many details.
- Valuable: Every story must be of value to the customer. In order to ensure that a story is valuable, the customer should be involved in writing the story.
- Estimable: The story should be such that it is easy for the developers to estimate, so that developers do not have difficulty during prioritization and planning
- Small: A well-written story should be small in effort (nothing more than three people weeks of effort). If more effort is required, there is high probability of estimation and scoping errors.
- Testable: In order to confirm that a story is Done, it needs to be testable. Anything that can’t be tested should not be developed; because, if it cannot be tested, then it cannot be confirmed as Done. This is defined in the Acceptance Criteria.
If you are interested in understanding more, I would urge you to read through the original transcript and postscript on the origins of the terminology.