How to write a Great User Story
Writing great User Stories is quite easy, if you follow these simple steps from this article. You will learn what makes a User Story great and later on I will provide a checklist you can use to improve the quality of your User Stories.
Why using User Stories?
A User Story is a great way to express requirements from a user’s perspective. They will help teams to focus on the users needs instead of adding too much technical requirements which may not be needed.
A user story is a promise to have a future conversation; it is not meant to document every aspect of the work, as you might in a series of traditional requirements statements.
User Stories leave room for conversation between the Product Owner and the Development team. A User Story describes what needs to be developed. The question “How do we develop a User Story?” is answered in the second part of the Sprint Planning Meeting, when breaking User Stories into tasks, the so called task break down. Generally, the development team should be able to decide how they want to get the User Story done.
What makes a great User Story?
I will provide and explain criteria, which helped the teams I worked with to raise the quality of User Stories and avoiding endless discussions and long-lasting refinement sessions and planning meetings.
User Statement
“As a <role>, I want <capability> so that <receive benefit>”
Starting a User Story with a user statement is one of the best ways to gain a common understanding of the users need. The idea is to be as specific as needed. Instead of writing “As a user, I want…” it is better to identify the users role. For example “As a course provider, I want to…”. Try to imagine an online learning platform like Udemy where different roles are using one system. When adding a specific role to the user statement it will be clear for Product Owners and Development Teams who will benefit from the value of the given User Story. Another common practice is to use Personas and put the personas in the role of the user statement.
Acceptance Criteria
The user statement alone will leave too much room for interpretation. I suggest Product Owners I work with to add at least one acceptance criterion to every story. Acceptance Criteria help the Team to identify, if the story is done or not, because it is quite easy to test the product increment against the acceptance criteria.
Suitable Size
As a rule of thumb, I suggest having User Story sizes between 1/10 and 1/6 of the team’s velocity. If a User Story is bigger than that try to slice the story into smaller stories. There is a nice article about splitting User Stories.
Product Dimensions
Mostly there are several stakeholders with an interest in the product the team builds. We can categorize those stakeholders in three groups: customer, business and technology. To cover their needs, it is a good idea to follow the “7 Product Dimension” framework:
- User: What type of users might access the feature? We covered this in the user statement, but sometimes the team needs more details.
- Interface: What will the interface look like? Are there interfaces to external data files needed?
- Action: What type of actions will users take when using this feature?
- Data: What data is needed to support those user actions?
- Control: Are there any constraints on what user can or cannot do in the feature or on data they can access? Are there any rules about what data we can store? Identify policies and/or rules defined by the team’s company.
- Environment: Which platforms (hardware, software) will be covered?
- Quality Attribute: What are customer’s expectations around response time and usability?
Satisfaction of Definition of Ready
The Definition of Ready is a list of criteria that a User Story must meet prior to being accepted into the upcoming iteration. This definition is developed by the Product Owner and the Development Team together to make sure everybody knows when a story is ready for development. That means you need to add all details to the User Story to make sure that the User Story satisfies the Definition of Ready.
INVEST Criteria
You will find all those criteria consolidated in the INVEST mnemonic:
How to create User Stories?
The Product Owner is responsible for managing the Product Backlog. This includes expressing Product Backlog items, prioritizing the items and ensuring the Development Team understands items in the Product Backlog to the level needed.
The Product Owner may create the Product Backlog Items (User Stories) or better, creates them and refines them collaborative with the Development Team. To avoid long-lasting refinement sessions, I think it is a good idea to let the Product Owner start creating User Stories and later on refine these stories together with the team. The Product Owner remains accountable for the User Stories, so I think he or she needs to know how to write User Stories and how to split them into smaller stories if necessary.
The Scrum Master needs to make sure, that Product Owners and Development Teams know how to write User Stories, what makes them great and how to split them into smaller pieces. During my work as a Scrum Master I recognized that many teams have problems expressing customer value with User Stories. My advice is to start a workshop with the whole Scrum Team to teach them why are we using User Stories and how we need to do this.
When not to use User Stories?
The Official Scrum Guide does not mention User Stories. The Product Backlog contains Product Backlog Items. Those items can be User Stories, Bugs/Defects and “other items”. Very often teams try to describe everything in a User Story, for example “As a developer, I want to update to mySQL 5.7.19, so that I can…”. “Stories” like that have no customer value. The customer doesn’t care about your technology. Writing User Stories help the team to focus on customer value. Sometimes you need to work on stuff that is not directly relating to customer value. If this work will enable the team to provide customer value in the near future, everything will be fine. You can describe this work in Technical Stories, Enablers or whatever. It is only important, that this work will result in a Product Increment which will describe the next level of your product. Then the Product Increment will enable you to provide a certain value for the customer in future stories.
When the team realizes, that updating to a certain mySQL version won’t create any value for future stories, the team should not do the update. This correlates to the following Agile Principle:
“Simplicity–the art of maximizing the amount of work not done–is essential”
How to handle Bugs?
Another kind of mistake is to describe bugs/defects with User Stories and estimate them with Story Points. A bug/defect is the difference between the current Product Increment and the original promise the team made to the Product Owner/customer when building the feature. So, there is a kind of gap. This gap needs to be visible and transparent, but not the play the blame game. It will help the Product Owner and the Development Team to get a kind of transparency about the quality of the product. If the team has a lot of bugs/defects to solve in a sprint rather than creating new value for the customer, the team needs to identify (during retrospective) how they can improve the quality of their work. I suggest teams to define a time box per bug/defect they want to spend to solve the issue. The time spend on solving bugs is subtracted from the team capacity. The Product Owner knows how much time in total the team has to create new value for the customer.
Conclusion
- Describe customer value with User Stories
- If a User Story does not create customer value, it is not a User Story, so don’t work on it
- Describe technical needs in a Technical Stories
- Describe bugs/defects as a Bug Product Backlog Item with a time box for solving this issue
- Add bugs as Product Backlog Items to the Product Backlog instead of having a separate Bug Backlog
- Track the number of bugs and the percentage of the team capacity you spend on solving bugs during sprints
- Identify improvements to raise the quality of your product, if needed
Checklist for User Stories
I created a simple checklist you can use when writing User Stories. You can download the checklist here:
Acknowledgements
This article was originally published on agile-goodies.com. You can find the article here: How to write a Great User Story.
