How to write an agile story
If you’ve been working in agile software development, you’ve probably come across stories. This article will explain what user stories are, where they come from, and how to use them. And most importantly, how to write an agile story. Let’s start with what stories really are.
What are user stories
In software development, “story” usually means “user story”. This is a concept from Extreme Programming (XP), one of the first agile frameworks.
User stories are a way of starting a conversation around requirements. Don’t think of them as a big requirements document though!
Agile is against writing big complex documents. Remember the agile manifesto value: “working software over comprehensive documentation”. And one of the principles: “The most efficient and effective method of conveying information to and within a development team is face-to-face conversation.”
Some people therefore define user stories as “a placeholder for a conversation”. The idea is that a user story starts with just a simple idea or phrase or placeholder. Maybe something like “As a user, I want to save my credit card, so I can use it make payments later”. And then conversations happen around that story.
People might start asking questions like “Can you save more than one credit card?”. “What sort of credit cards do we support?”. “Where do we store the data?”. Or “how do we make it secure?”. And all those conversations are where the value is. Not in writing documents.
The answers to those questions might become new user stories. Or they might become acceptance criteria on that user story. Or they might turn into other epics or themes or other types of backlog items.
Remember – not everything in a product backlog needs to be a user story! There are times when you might want to use tasks instead. Or epics or themes and so on.
How to use stories in agile software development
While user stories come from Extreme Programming, they are one of the common types of Product Backlog Items (PBIs) in Scrum. And since Scrum is the most popular agile framework, that is often where you see them.
Mike Cohn, an influential Scrum author, made them especially popular. Even more so after his landmark book “Agile Estimating and Planning” was published. I don’t love everything in that book, but it is a very influential and important work.
So, user stories are often decomposed from an epic (a higher-level backlog item). They represent a small slice of behaviour or functionality in software. Decomposing epics into stories usually happens in Backlog Refinement.
Then, a team will often pull some user stories from the product backlog into the sprint backlog. In Scrum, this happens in a Sprint Planning event. So user stories are often a main part of the scope of a sprint.
How to write an agile story
So let’s get to how to write a user story. A user story usually has three main parts. A title, a description, and acceptance criteria. Let’s go through each of those.
User story title
A user story should be a very short summary of what the user story involves. A common mistake people make is to create a long title, such as the Story Normal Form description (see below). Don’t do this! It should just be a quick placeholder that says what it is about. For example, “show latest messages” or “update score”.
User story description
The description is where you start fleshing out the details of the user story. It often starts with “Story Normal Form”. This is where you write it in this form:
As a [actor of some kind], I want to [do something], so that I can [get some outcome or benefit].
So an example might be “As a normal user, I want to be able to delete old messages, so I can keep my inbox from getting too full”.
The importance here is that we are identifying the actor or person (so we know who we are talking about), we are identifying what they are trying to do (so we know what we need to build), and we are identifying the value (so we know why we need to do it). The value is very important since it can help in prioritising the story.
You can of course add other things to the description of your story. Thoughts, questions, comments, additional information, test data, etc. Whatever you feel is relevant.
Remember, user stories are a living artifact. You don’t have to get all the details down right away! You can always go back and add or change things. That is, until it goes into development, at which point it should stop changing. Any changes at that point should be a new backlog item.
People often want to add things like diagrams, documents, screen mockups and so on. That is fine but make sure to link out to those, rather than attach or embed them into the story. User stories are not a form of documentation. And the tools that manage them are not designed as knowledge management tools.
Acceptance criteria
A user story also has one or more acceptance criteria. These are cases or scenarios that need to be tested before it can be accepted. (Along with the rest of the Definition of Done).
Acceptance criteria are usually written in a “Given When Then” format. Which looks something like this:
“Given [some condition], when [some action or event occurs], then [some behaviour changes]”.
A user story will usually have a few acceptance criteria. If it has a lot, you should probably split it up to keep your batch size small and your work flowing.
Good practices for how to write an agile story
Here are some good practices for writing a user story.
You can remember these by the INVEST criteria (Independent, Negotiable, Valuable, Estimable, Small, Testable).
Independent: a user story should be independent. You should be able to work on it alone, without other stories or tasks.
Negotiable: everything in the product backlog should be negotiable. Including all the user stories. Otherwise it’s not a backlog, it’s a scope list.
Valuable: It should be valuable. Otherwise, why do it? That’s what the “so that…” part is meant to capture. The value delivered by the story.
Estimable: It should be able to be estimated. Even if you aren’t going to estimate it right away – or ever!
Small: Small is better, always better. This concept comes from the Lean idea of “Small batch size”. Each story should be able to be completed in a sprint. Ideally, half a sprint or less.
Testable: a user story has to be testable. Otherwise, how do we know it is done? We start thinking about testing when we write the acceptance criteria.
Summary
I hope you found this article helpful, and that you now have a better idea on how to write an agile user story. Do you still have more questions? Let me know in the comments!
