Chris is at Agile 2011 in Salt Lake City today, and part of prepping for his Tuesday session on Agile Requirements: User Stories and Beyond included reviewing the following chapter from The Elements of Scrum, by Chris Sims & Hillary Louise Johnson (c’est moi). Here is the text of that chapter in its entirety:
Computers make it easier to do a lot of things, but most of the things they make it easier to do don’t need to be done.
~ Andy Rooney
User stories are the building blocks of the product backlog. Combined with conversations and acceptance criteria, they are an efficient and effective way for product owners to provide requirements to the team. Notice how these aren’t called “product manager stories” or “system architect stories”? We call them user stories to keep the focus where it belongs—on the things real people are going to need the software to do for them.
User stories are often written out by hand on index cards, although some teams do opt to use software tools to record them. Many teams use one particularly popular format for a user story; it’s not the only way to write a user story, but it is a good way. Here’s the template:
This format for expressing requirements captures a lot of information in only a few words.
The first line:
tells us who wants the functionality. Remember, we build software systems and products for people!
The second line:
tells us what the desired functionality is.
Finally, the last line:
tells us why this user wants this functionality. Having stated who wants what, and why, here is an example user story in this format:
As a member of the Madonna Fan Club,
I want to order concert tickets by phone before they go on sale to the general public,
So that I can get great seats and feel special.
Armed with a sense of who our somewhat geriatric users are and what they value, we can create a phone ordering system that will give them a lot of value. We can have Madonna record a special greeting: “It means a lot to me that you are a member of the Madonna Fan Club. As my way of saying thank you, I’m holding a block of the best seats just for you…”
Traditional requirements often indicate the “what” while leaving out the “who” and the “why.”
But maybe Madonna’s fan base consists equally of old-timers and impressionable 12-year-olds who think she is retro-fabulous.
The Madonna team might push back, asking their product owner if a web-based system might not work just as well for both audiences. Perhaps the team could deliver such a system in half the time it would take to build the phone-based system.
As good as this user story template is, and we think it’s pretty good, it’s not the One True Way to write user stories. Any format that leads to a shared understanding, and facilitates the production of valuable software, is fine. Remember, it’s not a religion; it’s a tool you can use to help your team succeed.
Variations on the Theme
The above user story format puts the focus on the user; they are listed first. Some teams prefer to move the focus to the user’s goal or the value, so they change the order around.
In order to
In order to
A User Story is a Ticket to a Conversation
User stories are not complete requirements or specifications; they are placeholders. They contain enough information to remind the team that there is something there to be done, but we intentionally don’t go into a lot of elaborate detail… until it’s needed.
When the time comes to elaborate on the user story, we prefer to do it in the form of a conversation between the team members involved. The goal of the conversation is to come to a common understanding of what the story is about, and exactly what needs to be done.
A live conversation is a much more efficient way to reach this goal than relying on written documentation. There is more information flowing, or if you prefer, the connection has much higher bandwidth.
Acceptance Criteria Make it Real
When you get to the point in your conversation where everyone thinks they have a common understanding of the user story, it’s time to write acceptance criteria. Generate a list of pass/fail tests, written in plain English, such that if they all pass, then everyone involved in the conversation would agree that the story is implemented as intended. Acceptance criteria answer the question: “How will we know when it does what it should do?”
It is useful for every user story to have acceptance criteria written by the product owner. For stories that the team will be working on soon, this sprint or the next, these criteria should be fine-grained and thoroughly understood:
customer’s email address is captured
Ideally, the team should be able to write automated tests based on the acceptance criteria, even before the functionality is implemented. For stories that are lower in the backlog, and may not be implemented soon, the acceptance criteria can be less precise; a few bullet points may suffice. Part of the work of grooming the backlog is to evolve the acceptance criteria.
Here’s how to recognize an expert product owner: they have all of the acceptance criteria defined and agreed to by the team before the start of the sprint, and these don’t change during the sprint. Be warned! This is not a trivial goal, and it usually takes some time before the product owner, and the rest of the team, learn what it takes to reach it.
Putting it all together
The user story, the conversation, and the acceptance criteria combine to form a complete requirements specification. The user story allows us to quickly, yet richly, capture ideas. In conversation we can elaborate and come to a common and actionable understanding of exactly what is needed. Finally, we capture our common understanding in acceptance criteria that are specific and testable.
©2011 Chris Sims, Hillary Louise Johnson and Agile Learning Labs. All rights reserved.