User stories are a brief description of a product written from the perspective of the end user. It may include some of the following: features, functionality, bug fixes, enhancement requests, infrastructure setup, or technical documentation. The purpose of a user story is to explain how a feature will provide value to the customer.
One of the key elements of the Agile approach is putting people first, and a user story puts the end user at the centre of the planning and execution of a product. These stories are informal and non-technical to provide real-life context for the development team. Reading user stories should give the team a better understanding of the product they are building and the value it creates for the user.
Overall, user stories help the team to maintain a user focus on their day-to-day work, which in turn drives collaboration, creativity and a better overall product.
Who is responsible for user stories?
There is no one single person or role within the Agile team responsible for user stories. In fact, everyone involved in the project can write user stories from the team members right through to the stakeholders. However, many stories are written during a backlog refinement or sprint planning meeting by the development team and the Product Owner.
It is also worth noting that who writes the user story is far less important than who is involved in the discussions of it.
How to write user stories
The following is useful to consider when writing user stories:
The Definition of Done:
Having a clear understanding of what is needed for the user story to be Done is important. The story can be considered “done” once the end user can complete the outlined task (often referred to as Criteria of Satisfaction) and when it meets agreed standards (Definition of Done).
Feedback:
Collaborating with users to capture the problem or need in their words. There is no value in guessing what they want.
Use ordered steps:
Write a story for each step in the larger process or goal.
User personas:
A shared understanding among the team of who the end user is and their specific needs.
Flow:
If a story is likely to take longer than the duration of a Sprint, it should be broken down into smaller stories or should be considered its own ‘Epic’. Estimating user stories is helpful when assessing whether stories need to be further slices to ensure a nice flow of work
Once the user stories are clearly defined, it is important to ensure they are visible to the entire team.
User stories template and examples
User stories are often written on index cards, sticky notes or if teams opt for a digital version, online software. An often used template template include the following:
As a [type of user], I want [some function] so that [some value].
Let’s break this down even further:
- [Type of user]: This is exactly who is using the product and their persona. The team should have a shared understanding of who they are and their requirements.
- [Some goal]: Here is describing the intent rather than a specific feature they want to use.
- [Some reason]: Lastly, this is the reason why they are trying to achieve this. I.e. What is the overall benefit they are trying to achieve? What is the larger problem that needs solving?
For example, user stories in practice might look like this:
- As a [user], I want to [specify folders to be backed up] so that [my drive isn’t backed up with folders I don’t need].
- As a [user], I want to [organise my virtual workspace] so that [I can feel more in control of my work].
- As a [manager], I want to [be able to understand the team’s progress] so that [I can report on success and failures with ease].
They don’t have to always follow this structure, however, this can be helpful in defining the Criteria of Satisfaction and the Definition of “Done”.
[You can read more about the Definition of Done in our other resources here]
Why create user stories?
We have explored what user stories are and how to create them, however, it’s also important to understand why creating user stories provides real value to teams. Sometimes for development teams new to Agile, user stories can seem like an extra and unnecessary step. But, stories provide the team with useful context and associate tasks with the value those tasks bring.
Some of the key benefits of user stories include:
- Stories drive collaboration. Having a clearly defined end goal can enable the team to work together on how best to serve the end user and meet that goal.
- Stories help define roles. Due to the concise and user-focused nature of stories, separating who deals with what and defining roles can be easier.
- Stories create momentum. Due to being small units of work, the team can celebrate regular wins which helps to create and maintain momentum.
- Stories encourage creative thinking. Stories help to drive the team to think creatively about how best to solve an end goal.
Summary
In summary, it’s clear that user stories provide some considerably substantial benefits. Putting the end user at the centre of the work and conversation creates value by helping teams to build a successful product and motivating them to do so along the way. Getting to terms with stories and using them effectively is therefore important for teams using Agile.
