Agile is conquering the tech world and user stories are at the heart of it. There’s hardly a person in the business of software development who doesn’t know the famous Connextra template: “As a <role>, I want <goal/desire> so that <benefit>.” Management attitude depicted by this Dilbert comic strip is fading away to oblivion.
The user story is a simple concept. It is easy to write, and that’s one of its strengths. But if you are new to doing it, it may seem difficult to get started. In this guide, we will show you how to write a user story in Agile.
What makes a good user story and why should you care?
At first glance, user stories seem to be just another template for writing down requirements. As long as all requirements are captured, what could go wrong?
As for the why. One of the most important artifacts of any Agile process is the product backlog that contains all the stories. The quality of the product backlog has a huge influence on the performance of the Agile team and its ability to deliver on time. The process of getting there is called “backlog grooming” and is often a game changer for the backlog quality. If your product backlog isn’t well-groomed, you will constantly face failed sprints, functionality not delivered on time, missing features, bugs, and things implemented not in a way you need them. Writing user stories is where your backlog starts.
As for what could go wrong. “Capturing requirements” is a flawed approach for Agile process. Requirements don’t exist on their own, they emerge while users actually work with the system. That is the main reason to apply Agile: even though you have a product vision, you don’t really know where you want to get at the end of the project. You have to figure that out while you go. If you want to apply Agile successfully, you need to step away from “requirement elicitation” mindset into the territory of “individuals and interactions,” “customer collaboration” and “responding to change.” The purpose of user stories is not to capture requirements, but to facilitate dialogue that will lead to finding the best solutions for the business needs.
How to Write a User Story in Agile
The best piece of advice for how to write a user story in Agile is: write stories, not tasks. But what does that even mean? Aren’t user stories supposed to be tasks for implementing pieces of functionality?
To answer that question, let’s recall the purpose of user stories. A user story isn’t supposed to be a replacement of a use case or IEEE 830 specification document. The purpose of the story is to start the conversation about what the business needs are and how it can be fulfilled with software.
Don’t Forget the Purpose
This will come as a big surprise to many product managers, so let’s repeat it again: a user story is not supposed to be final specification handed over for implementation. It’s supposed to start a conversation between techies and business people from a common point of understanding. That’s the reason why the common format is so informal: “As a user, I want to…” As a user or product owner, don’t worry about missing details when you write the user story: you will figure them out very quickly after you start talking, with an added bonus that you will talk about important ones first. Trying to provide all the details upfront gives a false sense of security and increases the chance that questions won’t be asked until the story is already in progress. It also increases the risk that important details will be lost between sentences and you will stand there several weeks later pointing at the story text yelling “it has been specified!” but will have to wait for another week or two until you get what you need, depending on your sprint length.
It also surprises many developers, so let’s repeat it once more: a user story is not supposed to be a final specification handed over for implementation. More often than not, your users will not be able to tell what they really need until you start talking to them. It doesn’t matter how experienced they are and how well they think their stories through: nobody can think of all the details, caveats and possibilities. Sometimes the users will only realize what they need once they start using the system. That’s normal and that’s why Agile even exists. It’s your responsibility as a developer in an Agile process to figure out the best solution and negotiate the details with the user to make sure it’s doable in adequate time with adequate resources.
INVEST
The advice above is pretty abstract, although it’s telling what to avoid (writing tasks) rather than what to do. Luckily, there is a list of guidelines for good user stories as well. It’s summarized by an acronym INVEST. Your user stories should be:
- Independent
- Negotiable
- Valuable
- Estimable
- Small
- Testable
Getting there is harder than it seems. Especially because “I have 4 out of 6, that must be good enough” doesn’t work. One way to achieve INVEST is to skip “Small” in the first step and then get it to the development team for breaking down to smaller stories. Possible ways of breaking a big story down depend heavily on a project, team, technology stack and business, so there isn’t really any universal piece of advice. In my experience, focusing on “Valuable” and “Testable” yields best results. “Independent” is something that can be sacrificed to some level more often than not, but be careful when accepting dependent stories into one sprint: you put the last one or two at risk of not being delivered.
Once you have your INVEST stories in your mind, you want to put them onto a paper card or into a software issue tracker (when truth be told, you’ll probably write them down first and iteratively improve them until they are good enough). That’s when the famous “As a … I want to … so I can …” intro comes to mind. Most of the time including a user role and purpose improves the story greatly, because putting oneself in user’s position immensely helps to understand the actual needs. However, if you find yourself struggling with what to put there (a frequent symptom of backend stories), you can use another template. Just write “A user can … so that she …” or even “A user can …” – that’s perfectly fine as long as it conveys the need and the purpose.
Not Everything Is a Story
Sometimes including a user role into the story doesn’t help at all. Certain business needs cannot be even expressed as a story – actually, there’s a handful of cases where you don’t want a user story. My first Agile coach had a dozen templates for different cases. Here are some examples:
- A change request
- A constraint: required performance, technology stack, database to use
- A technical requirement: communication protocol, security standard compliance
Don’t try to squeeze such requirements into the user story format, just write them down in plain text. There is an indicator that you need to rethink whether to stick to user story format or not. It’s when you put something that doesn’t really sound like a user into the user’s placeholder, like your company name or software component where the change is required. Avoid stories like “As Big Company Inc. I want to send invoices to my customers” or “As WebCrawler I want to scan archives I find on the web.”
Specifying software components as users is not always verboten: there are cases, when it’s perfectly fine. If you want to change a component named Leonard that is used by a component named Penny, then it’s fine to write a user story in a format “As Penny I want…” The story features Penny as a user, but it is about extending or changing Leonard. That’s actually a great way to write user stories for backend systems where there is no direct user. E.g. “As customer emailer I want to get a list of recommendations for a user so I can include them into the weekly digest” is a good example of a story written for a data analysis component.
User stories for backend systems are usually a hard topic on any project. You may read the following article to get more insight on how to write good backend stories here.
A Note About Details
Even though it’s important not to try to get all the details upfront, it’s also important to include details up to a certain level. In most cases a user story or a requirement benefits from ‘acceptance criteria’ section that restates what must be achieved for the story to be considered done. Listing one or two test scenarios can fulfill this purpose perfectly. A list of bullet points with desired KPIs can work just as well. The purpose of the section is to make clear to the developers when they can consider their work done – whatever format helps you achieve this goal is fine.
The Big Takeaway
The most important takeaways to keep in mind when figuring out how to write a user story in Agile are:
- Write stories, not tasks
- Follow INVEST principles
- Start the conversation as soon as possible
Agile is all about conversation and collaboration, not about following written contracts. If you feel a need to document everything before starting the work, this is an indicator that you’ll have hard times applying Agile at your organization. Don’t try to get everything specified upfront, but talk to your team. It will work wonders.
Further Reading on How to Write a User Story in Agile
Mike Cohn’s “User Stories Applied” is a classical work on how to write a user story in Agile. It contains a lot of practical advice, dos, don’ts, examples and war stories. Most of the advice in this article can be found there, with more detail. Information density per page is at times overwhelming. Chapter 5, “Working with User Proxies” can be especially eye-opening.
Mike Cohn also has an active blog on all things Agile.
Roman Pichler’s “Agile Product Management with Scrum” is a great primer for how to be a product owner. Chapter 3 “Working with the Product Backlog” explains the importance of backlog grooming and contains a list of good and bad practices.
