“The customer is always right.” Though this motto is often contested in the retail world, it’s not a bad one to keep in mind for Agile projects. In fact, customer satisfaction is listed as the highest priority in the Agile Manifesto.
In Agile methodology, it is common practice to include user feedback in the development process. Agile teams welcome this external perspective to ensure they are on the right track and that the final deliverable will suit the customer’s needs.
When breaking projects down into an Agile work structure, teams will explore the customer perspective by writing a user story. But before we delve into how to write user stories, let’s first outline what they are.
What is a user story?
A user story is a small unit of work in an Agile workflow. It is a short, written explanation of a particular user’s need and how it can be fulfilled. There is no room for jargon in a user story. It is written in easily accessible language to provide a clear picture of what the user requires. The technical details can be discussed at a later stage.
Every user story involves a short-form request that is completed in one Agile iteration or sprint, which normally lasts about one or two weeks. Teams measure the complexity of their user stories with story points, helping them to accurately estimate how long a particular request will take.
A user story is similar to a use case but is not as detailed. The former is a very brief description of a planned action item, while the latter will likely contain extra sections such as required conditions, various paths a user might take in using a product, and workflow diagrams.
User stories: Examples
User stories follow a simple template. The chosen user story format will outline the “who,” “what,” and “why” of a particular requirement.
- Who wants something?
- What do they want?
- Why do they want it?
The following template is one of the most common:
“As [persona], I want to [action], so that I can [benefit].”
For each story, the writer will include a user persona, the action they wish to take or the ability they wish to have, and the benefit they hope to achieve as a result. Here are some examples:
Example 1: An online gamer
“As an online gamer, I want to have a multiplayer option so that I can play online with friends.”
Example 2: A design team lead
“As a design team lead, I want to organize assets, so I can keep track of multiple creative projects.”
Example 3: An e-commerce shopper
“As an e-commerce shopper, I want to filter my searches so I can find products quickly.”
Now that you know what a user story looks like, you can get to work creating one.
Five steps for writing user stories
Want some practical advice on how to write user stories? Use these five steps as a guide:
Step 1: Outline acceptance criteria
The definition of done is the set of criteria that needs to be fulfilled for your user story to be considered complete. Define the specific acceptance criteria for each user story and use it as a checklist.
Step 2: Decide on user personas
Conduct extensive user research by creating surveys, hosting focus groups, and reading user forums. Analyze your data and search for patterns to identify your key personas.
Step 3: Create tasks
Break your user story down into numerous tasks to make it more manageable. If it is a complex requirement, you can also add subtasks. Include detailed descriptions, so your team is aligned on what each task requires.
Step 4: Map stories
Use story mapping to structure work in a large process. In this case, your user stories will take the form of ordered steps.
Step 5: Request feedback
Speak to users and potential customers to find out what they want. Ask them for their opinions on existing products or if they have suggestions for new features. Incorporate this feedback into your user story.
What makes a good user story?
So, you’ve written your user story. But how do you know if it’s any good?
Agile teams assess the quality of stories by using the INVENT acronym. This stands for:
- Independent: The user story should be independent of all others. Because they are not connected, they can be worked on in any order.
- Negotiable: A user story should be flexible enough to allow for negotiation between the customer and product owner.
- Valuable: What value does the user story bring? If you cannot find any value, the story should not be completed.
- Estimable: You should be able to estimate how long a user story will take so that you can effectively manage your time.
- Small: The user story must be small enough to be completed within a single sprint.
- Testable: You must be able to test your user story in line with quality assurance standards.
If a user story does not meet the INVENT criteria, it should be rewritten or removed from the epic. However, if it does, your team members can get to work. Schedule daily Agile meetings to check on their progress and ensure they are on track to complete the user story within the sprint timeframe.
Benefits of user stories
Why write user stories in the first place? Because they offer numerous benefits for an Agile project. Here are a few examples:
- Simplified format: User stories are written in easy-to-understand language. This eliminates confusion and makes it easier to grasp what the customer is looking for.
- Increased flexibility: Because user stories don’t go into technical detail, they can be molded to fit changing situations.
- Improved collaboration: When team members are aligned on one goal, they can work better together and collaborate easily with other project stakeholders.
Though the benefits of writing user stories are significant, a product owner must also consider the potential disadvantages.
Disadvantages of user stories
Here are a few user story pitfalls to watch out for:
- Incomplete stories: Though the language is intended to be informal, sometimes user stories are far too vague and exclude necessary details.
- Insufficient time: Writing a good user story takes time. It requires extensive research and regular communication with stakeholders, a fact that is sometimes overlooked.
- Narrow vision: Because user stories focus on one single requirement, they can be hard to scale, and teams can sometimes lose sight of the bigger picture (in this case, an epic).
Before you start your user story, take some time to identify potential risks or disadvantages and outline how you aim to counteract them.