Writing Kick-Ass User Stories

5 easy steps to better stories.

TL;DR Well-written user stories are the backbone of an efficient agile software development process. When done poorly, the wrong thing gets built and teams waste enormous amounts of time on costly rework. When done well, teams are able to confidently forge ahead knowing they’re building the right thing. Investing the time to write kick-ass user stories also provides transparency to those outside of the scrum team through clearly articulated value of the work they do and what (specifically) is being built.

Poorly written user stories are pervasive in agile software development. Product owners know that acceptance criteria are important, but often write stories containing just a sentence or two of detail (if you’re lucky). Teams need more than this to properly prioritize them against other work in their product backlog, clearly understand the value of what they’re working on, feel confident that they’re building the right thing, and know when to call the story done. As the primary method of communicating what new functionality users desire, poor user stories often result in the wrong thing being built, ultimately leading to wasted time, effort, and money reworking issues.

Let’s recap the original intent of user stories as a fundamental part of the Scrum process:

What are User Stories?

User stories are short descriptions of new system behavior told from the perspective of a — you guessed it — user! They represent:

• Placeholders for a Discussion — Between the product owner and development team. No amount of detail in the story can replace the conversation that must take place. It not only provides clarity of requirements but can also unearth new ideas to incorporate into the story, provide insight into technical feasibility and design options, and encourages discussion around scope and timeline tradeoffs.
• Increments of Value — When complete, a user story should ultimately create business value by enhancing the user’s experience in some way. If it doesn’t do this, then why work on it?

Who Writes User Stories?

Anyone can write them — great ideas can come from anywhere, and most often come from those closest to the work. While the product owner is ultimately responsible for what the development team works on and when, everyone is responsible for ensuring only good user stories make it into a sprint, regardless of who originally wrote it.

What’s In a User Story?

User stories contain:

• A Description — Tells the world who the user story is being created for, what is being created, and why. This is most often presented in the format of As a <user persona> I want <some new functionality> so that <some value is created>.
• Acceptance Criteria — Define the new system functionality, most commonly presented as a bullet-point list of independently testable system behaviors. These include both functional and non-functional requirements (performance, reliability, extensibility, etc) as well as positive and negative test scenarios.
• An Effort Estimate — Indicates the relative complexity of the user story, typically measured in story points. The estimate is used for planning purposes to understand both when the user story might be completed as well as prioritize the story against others in the product backlog.

So how does one write a good user story? To demonstrate this, let’s walk through an example of turning a poorly written user story into something any development team will love.

My Crappy User Story

This user story leaves a lot to be desired, specifically:

• The description offers little information regarding what (specifically) is being worked on, who is asking for this, and why we’re working on it now.
• No acceptance criteria are listed, making it very vague as to what the developer should actually do and how the story will be considered done.
• No estimate is provided, making it nearly impossible to understand the effort requirement, prioritize it against other user stories, identify opportunities for phased/iterative development, etc.

In 5 easy steps this user story can be turned into a kick-ass story the development team will love. Let’s check out how using a cheesy acronym, DARES:

D — Description

A — Acceptance Criteria

R — Refinement

E — Estimate

S — Split

D — Description

Let’s start by fixing the story’s title, which tells everyone what this user story is about. It’s how it’ll be referred to every day in the daily scrum and how other teams, leadership, etc. will understand the work being done from an outsider’s perspective.

Note: Some teams copy the description into the title (i.e. — as a…I want…so that…). Don’t do this — it makes it difficult to read the team’s backlog and can be confusing to those outside of the team.

Let’s check out a rewrite of my crappy user story’s title:

The new title makes it clear what is being worked on (adding additional password strength requirements) and why (existing requirements pose security risks). It doesn’t explain exactly what will be developed, but gives a good-enough indication of what’s going on to those unfamiliar with the topic.

Next, let’s work on the description. User story descriptions should clearly indicate who the new functionality is intended to serve, what the new functionality is, and why it’s important to the target user.

The most popular format for writing the description is as follows:

As a <user persona>…
I want <some new functionality>…
So that <some value is achieved>.

Occasionally user stories don’t fit into this format very easily. This most commonly happens for small, incremental changes that build upon a prior story. When this happens, try the “improve user story” format, where the who and why are assumed to be identical to the user story it’s building upon:

We have <some system functionality>.
We want to have <some different system functionality>.

If neither of the formats above fit your user story, try writing it in simple, every-day language. The description’s format doesn’t really doesn’t matter too much as long as it contains the who, what, and why.

Let’s check out my user story after adding a good description:

With this description, we now know who the user story is being developed for (Medium account holders), what will be developed (more strict password strength requirements), and why this functionality matters to them (to reduce the likelihood of their account being hacked).

A — Acceptance Criteria

Acceptance criteria tell the development team what (specifically) needs to be built. Without acceptance criteria, the team can waste time building the wrong thing.

Good acceptance criteria outline both functional and non-functional requirements (performance, reliability, extensibility, etc.) and contain positive and negative test scenarios that must be captured in order for the user story to be considered done. The more detailed the acceptance criteria, the easier it will be to estimate accurately and more confidently the development team can forge ahead knowing they’re building the right thing, so invest the time in writing them!

Let’s check out my user story after adding some acceptance criteria:

R — Refinement

Talk to the development team! Hold Backlog Refinement ceremonies at least once per week and create a forum for them to ask questions, express concerns, and provide feedback. Refine the acceptance criteria until everyone agrees on what (specifically) needs to be built.

Let’s check out my user story after refining the acceptance criteria:

E — Estimate the User Story

Good estimates enable efficient prioritization against other stories in the product backlog and can encourage discussion around how to effectively split the user story to deliver the necessary value now while deferring other, lower priority requirements for future iterations. The goal is to quickly arrive at a good-enough estimate that reasonably reflects the complexity of the user story.

Let’s check out our user story after estimation:

S — Split the User Story

Splitting user stories enables product owners to weigh the relative value of them against one another to optimize value delivery through iterative or phased development. Smaller user stories are also easier to estimate and tend to move through the software development lifecycle more quickly. When splitting user stories, be sure each resultant story still follows the INVEST principle.

Let’s check out my user story after splitting it into 4 smaller stories:

With the user story now split the team is able to weigh the relative value of the resulting stories against one another and those in the product backlog to prioritize the most important work first while deferring others to later sprints.

Writing good user stories isn’t hard, but it requires a commitment to the time needed for thorough research, documentation, discussions, and iteration on requirements to get them right. Investing in this process, however, will reap many rewards and reduce the amount of rework required when the wrong thing is implemented.

Try this technique out during your next Backlog Refinement or Sprint Planning ceremony and let me know what you think — I’d love to hear your experiences (good or bad) in the responses!