Join Doug Rose for an in-depth discussion in this video Creating user stories, part of Agile at Work: Planning with Agile User Stories.
- When I was traveling through a large airport, I didn't have much time, so I jumped into a fast food restaurant. There was a big sign that welcomed me at the door. On the sign it said, super size everything for a dollar. When I waited in line, I was thinking about if I should super size my french fries. I wasn't interested in super sizing my drink. That's always a bad idea before a long flight. I was a little bit confused about how to order. Would they super size everything for a dollar? Then we'd get a huge soda and fries. Or is it that I have the option to super size anything on the menu? Then I could pick and choose what I wanted super sized.
For each super sizing event, I'd pay a dollar. When I got to the front of the line, I placed my order. Before I had a chance to clarify, the person asked me very quickly, would you like to super size anything on your menu? Just that little snippet of conversation cleared up my confusion. I could super size anything I wanted on my order for a dollar. Anyway, it was too late. By that time I decided it was a bad idea to eat a huge pile of fries. When planning a project, many people assume that when you write something down it becomes much clearer.
Project requirements strive to be written in clear, direct language. What could be clearer than super size everything for a dollar? It's usually when you turn this clear language into work that you realize that there's a lot of room for misinterpretation. Unfortunately, it's almost impossible to predict how each person will interpret your language. I'm sure hundreds, if not thousands of people, walked by that fast food sign with little confusion. Often, a quick conversation is the only way to make sure that everyone knows the work.
Agile projects don't use traditional project requirements. Instead, the product owner maintains a set of user stories for the project. A user story is a conversation vehicle. It's a short story from the user's perspective about what they find valuable in the product. A common user story format is as a user role, I want/need/can/etc a goal so that reason. The user role is the bundle of user experiences that a product owner defines before creating user stories.
Now they take that bundle and attach them to some value. Let's go back to our website. Say you've created a user role called premium customer. Now you've attached some business value to that role. For this story you might say, as a standard customer, "I want to see a list of benefits of upgrading to a premium customer so that I can see if it's worth the cost." The user story accomplishes two things. First, it uses the customer's language. The product owner doesn't need to know how to build a web server to ask these questions.
There's no talk about the how the website will work. The story is only about the what and the why. This'll be much easier for the product owner to understand and prioritize. The story format is important because of what it doesn't say. It leaves the technical decisions up to the team. It's very important for the product owner to not swim in the developer's pool. They need to leave the how to the development team. Second, the story is immediately linked to some business value. You could tell from the story that the standard customer really wants to find out about the benefits of upgrading.
Maybe there's a better way to do this. Maybe a window after the user logs in. A good way to create user stories is to think about the three Cs. This comes from the world of extreme programming, and it stands for Card, Conversation, and Confirmation. User stories are best recorded on a 3 x 5 index card. Many product owners are tempted to create a user story spreadsheet. If you try to do this, what you'll find is that it's more difficult to communicate about individual stories.
You don't want to overwhelm the group with a list of information. Instead, you want to have a group conversation. Many times when an Agile team is starting out, they're very focused on the format of a user story. They make sure that every story starts with, as a user role, and ends with, value goal. What they forget is that a user story is a means to an end. It's not about the format. It's about having a group conversation. The final part of the card is the acceptance criteria. This is the confirmation that everybody knows how to deliver the story.
This is typically written on the back of the card. In the language of extreme programming, this will be the definition of done. It's very important that the acceptance criteria closely match the user story on the front of the card. It should be the result of the conversation with the development team. This will go into much greater details on how to deliver the story. The acceptance criteria are a good way to keep the user story from becoming too convoluted. You can add a lot of details to the acceptance criteria without putting it on the front of the card.
- Starting with user roles
- Creating user stories
- Grouping stories with themes or epics
- Creating a project charter
- Writing your release plan
- Avoiding common pitfalls