User stories are a common practice in Agile but what are they and why do we use them? Read about my experience here, plus if you get to the end there is a useful story writing handout.
In traditional waterfall environments requirements for products with high degrees of certainty are written upfront and handed to teams to build. These requirements typically focus on the solution itself rather than the problem they are trying to address.
When working in Agile product development, requirements are complex and often not known and well understood. So we need to gather and define requirements in a more emergent manner, giving autonomy to teams to find the best solution, therefore required. I give you ….user stories.
Thought leader Dan North says in his book “What’s in a Story” that a user story is “A description of a requirement and its business benefit, and a set of criteria by which we all agree that it is ‘done’."
Let’s break that down a bit further...
User stories describe a requirement of a product from a user’s perspective (hence the name). They don’t describe how this requirement is to be fulfilled, merely what it is - AND what benefit the user is trying to get out of this requirement.
So unlike traditional requirement specifications, where we would indicate how we are going to fulfil the requirement - i.e. a solution - a user story explicitly does not. Why is this?
Well, have you ever been one of those people in a development team when you’ve been told what to build, why and how to do it? Even if you have some questions to ask about that requirement, and you have a ton of ideas on how a solution could look? That, after all, is what you’re paid for… right?
User stories give the product developers autonomy to be able to decide how to develop the product. They are closest to the product and best placed to make these decisions anyway.
User stories are an emergent way of refining requirements. A traditional big up-front requirements specification is guessing what the requirements will be. User stories are written and split down (more on story splitting in another blog) in a just-in-time manner to ensure the team use their latest knowledge of the user's needs, and how the product is developing.
Anti pattern alert... One team I encountered had a BA write 500 requirements up-front (analysis paralysis). They wrote them in a nice spreadsheet - by themselves - and handed them on to the team. When the team started to work on these requirements they had no idea what they meant, they were not broken down into how the team would deliver the work, it was not a good ‘story’. 18 months later the team successfully finished this component of work and I analysed the requirements delivered. Of the 500 user stories written by the BA only 80 had been delivered by the team. The team had written around 900 of their own user stories in their place, splitting work into stories they could understand and deliver. The BA’s work upfront had mostly been a waste.
As with all Agile practices, a strong focus should be on conversations and embracing diversity of thought. A user story presents a product developer with an opportunity to discuss the requirement with their customer - via their Product Owners, Stakeholders, or the customer themselves. It provides them the autonomy to flex their creative and collaborative muscles as to how this can be achieved, with a primary focus on value.
We want our teams to be able to discuss requirements and come up with the best possible solutions for them. By understanding the user's real needs teams are able to design solutions that are more aligned to these needs. Also by collaborating we get the benefits of diversity of thought, and group understanding.
Anti pattern alert... I have seen, on numerous occasions, the Product Owner or a Business Analyst write the user stories alone and pass them to the team when they are ready. WRONG, don't do it! You may as well write a normal specification document.
Doesn’t that lead to lots of iterations of a story? Yes - that’s the point. User stories present everyone with an opportunity to test our assumptions about what the requirement is, and how we should resolve it. We will have many ideas, discuss them, and refine the story as a result. This conversation provides clarity and confirmation on what we are trying to achieve.
OK, so far so sensible. But, surely we need to define how we’re going to build the thing that will fulfil the requirement?
Done (or Definition of Done)
And that’s where those ‘criteria by which we all agree it is done’ - come into play. We write ‘acceptance criteria’ for a story, and these criteria will really start to shape the ‘how’ in terms of what we will build, and provide a level of quality assurance. I will write another blog around user stories acceptance criteria soon.
Finally I just want to touch a little on how we write user stories. User stories were traditionally written on a physical card. Physical cards are easy to move around and work with. Physical cards help to keep them brief and transient. A physical cards aids Agile estimating, planning and tracking.
But more and more nowadays our teams are distributed and dispersed. To overcome this we often use a Digital Agile Planning tool, there are many, none are perfect.
Anti pattern alert... Digital Agile planning tools don’t restrict the content of a user story. What was once a short description of a requirement can, in a tool, often become an over-detailed account of a requirements. So remember - keep them brief.
Okay, so do user stories replace up-front detailed specification? Well no… A detailed requirements specification written upfront has two main problems.
Big up-front design assumes that we can accurately define requirements before we know a lot about the user and the product, so is highly likely to be inaccurate. With story writing we use emergence to define our requirements in a just-in-time manner as we learn more about the product and users.
Rarely are big up front requirements specifications updated when the product and solution has changed. Effectively they have little use once they are written, other than providing the author with a sense of achievement.
In agile we can ensure our teams always maintain documentation every time they update the product, this can be system designs, operational guides, whatever you need. Typically a Definition Of Done forms the teams quality criteria and would therefore ensure teams update documentation in an emergent manner.
User Story Writing:
- Protects against work up-front that can be wasted
- Is an emergent approach to defining requirements
- Provide options and prevent early commitment
- Are a starting point for collaboration and discussion
- Can be changed or removed as development progresses
- Describe a business need or problem, not a solution
User Stories ARE NOT:
- Detailed and complete requirement specifications
- Contractual agreements “signed-off” up-front
If you want to learn more why not look out for our Story Writing Fundamentals course.
You can also download our handy user story handout.
Oh and look out for some future blogs...