Why user stories rule
Today I spent the entire day in a room full of people, going through 16 pages of user stories with a customer. A week ago they had never heard of user stories, let alone written one. They absolutely loved it. They understand what they want, we understand what they want, and we’ve now got an excellent set of requirements for the system they’ve hired us to build.
Having your customers tell you what they really want can be challenging, having them write a set of formal requirements can be impossible. In large part because writing requirements is difficult, and people basically don’t know how to do it.
Luckily, Mr. User Story is here to save the day. Many customers have no prior knowledge of user stories, so you need to sell the concept. You need to explain why user stories rule. They’re high level, they focus on functionality instead of technology, and they’re easy to read wether you’re an engineer or a paperboy.
Below is simple how-to, hopefully it can help your customer grasp the concept of user stories.
Begin by setting up a list of known roles that are in some way interacting with the system or product to be built. Examples could be “End user”, “Administrator”, “Sales manager”, “Economy” etc.
The user story – introduction
The actual requirement should be formulated as something we refer to as a “user story”. This is basically a sentence formulated in a particular way. The point of this sentence (or story), is to ensure that the solution to the requirement will provide actual value to a known person or role. We need to understand who has a problem, what the problem is and why it is a problem.
As a <role> I want <goal / desire> so that <achieved value>
Confused? I’ll explain in a second – let’s just go through the document setup first.
Segment the document, don’t just list 50 user stories in a row. Sort them by functionality, or possibly by which part of your company that will be using the result. How many stories and how detailed you make them is up to you. You should probably spend more time on the stories that are most important to you now, and then we can build on the rest later on. You’ll want to order the stories roughly by priority as well. This way you’ll spend most time on the most important requirements when discussing them with the supplier.
The user story – why and how
The goal of the story can be very specific, but it’s often better if it’s not. It may be best if the story doesn’t tell us HOW to solve the problem. Don’t worry about the solution, or ponder about technical challenges. We need to know what you want and how, let us figure out the best way to solve it. Focus on defining the problem and explaining what value is gained by fixing the problem.
Example #1: A circular story (not so good)
- As a book store owner I want an SMS platform, so that I can send text messages
Example #2: A concrete story (better)
- As a book store customer I would like to receive a text with a tracking number, so that I know when my books will arrive.
Example #3: A generic story (even better)
- As a book store owner, I would like an effective way to communicate order information, so that I can reduce the time spent following up my customers.
The first story isn’t very helpful. Why do you want to send text messages? Who do you want to send them to? The second example defines a specific role with a specific problem, and clearly explains how this will add value. The third example also tells us what the goal is, but contains no specific information about how to solve it.
The second and third story are both okay, but may lead to different results. The second example will probably lead to a solution using text messaging to communicate, and it may be limited when it comes to what kind of information we can send to the customer. The third example doesn’t limit the communication form to text messaging, and is also more high level about what kind of information we can send.
Also note that the defined role is different in example #2 and #3. It’s basically the same goal, but example #3 focus on the role that has most to gain from the story. It’s great that each individual customer can receive a text message, but it’s even better that the book store owner can reduce the amount of manual work involved in her business. Example #3 does a better job of explaining how we can reduce cost and increase value.
So, is example #3 perfect? Not without more detail:
Additional stories and requirements
To help detail a user story, you may need to add additional stories and / or acceptance criterias below the first one. The main problem is to understand when to stop. For larger projects, the number of stories can become unmanagable. Stop as soon as all parties have a broad understanding of the problem at hand, and all high level requirements have been addressed. If you are lucky enough to have a customer that accepts an iterative process, you may proceed with mockups and prototypes to get the final details right.
Congratulations, there is now a reasonable chance that the result of your effort will match the expectations!