Agile fundamentals for teams

In this video, we’re going to look at writing user stories. We'll consider their purpose, how you identify users and how to use them in your product backlog. 

User stories capture the needs of users for your product or service. They aim to encourage teams to take a user centred approach. This is because they focus on the problem, not the solution. As a result, it ensures that every part of what you're building meets a specific user need. They help you stay focused on building something that solves a real problem for the people who will use it. 

When writing user stories, it’s important to be specific about who the user is. Avoid vague terms like "everyone" or "all". Instead, think about different groups or individuals who will use your product. For each of these, their needs may vary based on what they do. The more specific you are, the more focused and helpful the user story will be. 

One common approach to writing User stories is using this simple template: 

• 'As a…' 
• 'I need to…' 
• 'So that…’ 

This format helps you define the user, their need, and the reason behind that need. 

Let’s look at two examples: 

• Example 1 is a valid user story. It focuses on the need, not a specific solution. It doesn't specify the approach you must use, to meet this need. There's lots of different ways you could solve this problem. 
• Example 2 is not a valid user story because it focuses on a solution. It assumes the user needs to contact the Leasehold Advisory Service. Assuming the solution too early can lead to mistakes, as it might not be the best way to meet the user's actual need. In this case, the user doesn't need to contact someone, they need to resolve the problem they're having. 

Once you have written a valid user story, you'll then write acceptance criteria. This acts as a checklist that defines what the product needs to do, to meet the user need. It doesn’t state how to do the work. It's about the expected outcome, rather than the output. Every user story will have its own set of unique acceptance criteria. 

Looking back at our example of a valid user story, the acceptance criteria might include: 

• The user understands how leasehold works in Wales. 
• They know what to do if there’s a problem with a leasehold or they want to buy one. 
• And they know how to resolve any issues. 

As mentioned, it doesn't state a solution. Instead, it's the outcome we're looking to achieve. You can then test the solution with users. Does the solution: 

• enable the user to understand how leasehold works? 
• enable the user to know what to do if there's a problem? 
• enable the user to resolve issues? 

Once the answer to all these is yes, the user story is complete. 

User stories will feature in your product backlog.  

From these stories, you can create tasks. These detail the specific pieces of work they need to do. If tasks are complex, teams can break these down further into sub-tasks. These are smaller steps to manage and track progress. This isn't always necessary, so find what works for you. 

To recap, user stories help you capture and prioritise the needs of your users. They focus on the problem rather than the solution. User stories and acceptance criteria tell you what to build and how to measure success. Adding these to your backlog helps focus the team on delivering value to users.