10 Best Practices for Writing User Stories
User stories act as the building blocks in agile development. They provide a framework on what is being expected to be developed by the development team.
A User Story has 3 parts
- Card
- Conversation
- Confirmation
Card
- The Card doesn’t include all the information needed by the development team
- The goal is to force a conversation to take place between the development team and the product owner
- The conversation is where the true understanding come from
- The card is a placeholder for a conversation that needs to happen
Conversation
- The conversation begins in the project kickoff, before the first sprint starts
- The developers will be asking questions, getting clarifications and surfacing issues for the Product owner to get more details on
- The Conversation continues sprint by sprint during product backlog grooming, sprint planning and elsewhere
- The scrum team decides how to document the conversation using simple notes or detailed meeting notes
Confirmation
- During the conversations, the product owner and development team identify confirmations to each user story
- These are similar to high level acceptance criteria
The most common template for writing a User Story
As a <user type>, I want <some goal> so that <some reason>
— Mike Cohn
In other words, we are answering the following questions:
- Who: For whose benefit are we doing this?
- What: What are we doing?
- Why: Why are we doing this?
User Stories – More
- Product Owner will write most of the user stories
- User stories that are big with limited details are called epics
- During backlog grooming, the epics are split into smaller more detailed user stories
10 Best Practices for Writing User Stories
1. Have a thorough understanding of who are the end-users or customers and why do they want to use the product. Discussions and conversations from the perspective of the user provide context to the user stories
2. Start working on user personas before writing user stories to get a clear understanding on characteristics, behaviours, attitudes, and goals that includes a benefit the persona wants to achieve, or the problem the character wants to see solved by using the product
3. Start breaking an epic into user stories. You will not get lost with the requirements in this way. Epic will act as the base story for all the user stories
4. User story should focus on “who, what, and why,” but not “how”. By focusing on the who, what, and why, the development team is empowered to find the best technical solution. Avoid technical details as well. Technical details will come later in the process and be incorporated by developers, testers, and systems architects
5. Keep the user stories simple and concise. Avoid confusing and ambiguous terms. Describe only one piece of functionality in each user story
6. Refine the user story several times. Validate with the epic to verify the scope associated with the user story
7. Include all relevant stakeholders in the user story writing process. This includes the quality engineering team as well
8. Add acceptance criteria to each user story. Acceptance criteria enrich the story and make it more precise and testable, and they ensure that the story can be demonstrated or released to the users
9. Add visualization for the user stories. Use methods like drawings, story and impact mapping, storyboards, and mockups or prototypes to visualize the functionality for the feature
10. Validate the user story with INVEST. INVEST is an acronym that helps evaluate your user story
I – Independent: Verifies whether the user story can be completed by the team. This validates whether there is a dependency on another team to complete the user story
N – Negotiable: Verifies whether the user story is negotiable. This will allow the development team to implement in a way that makes the most sense for them using the existing common routines or libraries
V – Valuable: Verifies whether the user story describes the value-added with the implementation of the user story
E – Estimable: Verifies whether the user story is can be estimated by the development team
S – Small: Verifies whether the user story can be completed within a sprint. If the story seems to be too big for a sprint then it needs to be further sliced into smaller user stories
T – Testable: Verified whether the user story consists of clear acceptance criteria including both the happy path and error conditions that can be tested
Additional Reading Material
