Part 1
The story of user stories
How to better explain user stories than with a story? It worked for me.
This is the first part of the user story series.
I will tell you a story and try to respond to some of the most common questions about user stories. The next part will be more practical, we’ll go from talking about stories to writing them and will learn some tricks to help us make them ready for the sprint.
Scrum Guide doesn’t say a word about user stories and there was a time I was wondering where to find reliable information about them. Should the backlog be composed of user stories only? If I don’t use the template “As a user, I want, so that…” is it not a user story? What about the stories that say “As a developer…” or “As a Product Owner…” etc.?
Today my aim is to shed some light on user stories, clarify some misconceptions around them and point you to the people who explain them best.
The story of user stories
I’ll explain the story of user stories as this was for me the best way to understand what matters about them and clarify any misconceptions.
User Stories come from the’90s. Kent Beck started talking about stories in his book “Extreme Programming Applied”. He explained that stories were “an antidote to requirements” that are “something obligatory or mandatory” and as such, are standing in our way to embrace change.
The idea came from a story a user told him about a new product:
“I type in the zip code and it automatically fills in the city and state without me having to touch a button!”
“If you can tell stories about what the software does and generate energy and interest and vision in your listener’s mind, then why not tell stories before the software does it?” — Kent asked himself why can’t we generate this vision of the product before we build it? Stories about who will use the product, what it will do, and why? We should have conversations to help us think things through. Jeff Patton, the author of the “User Story Mapping” book insists that
“stories get their name from how we use them, not how we write them.”
The Template
Then along came Rachel Davis from a company called Connextra who invented the template many of us use today, it goes like this:
“As a user, I want…, so that…”
She tried to help her co-workers write stories on small cards in an organized way. The template reminds us about the three most important things: who wants it, what do they want and why.
Put yourself in the shoes of the user and think about their needs from their perspective, for example:
As a mobile phone user, I want to check the weather forecast for my location so that I don’t have to look it up every time I travel to a new place.
Again, what you write on the card is supposed to be only a starting point to drive the first conversations about the new idea. The concept of a card comes from Ron Jeffries’s 3Cs: Card, Conversation, Confirmation.
You write your idea on a card, actually currently in a software tracking tool or on a post-it, then you have a conversation about it with the people that will build it (the development team) and then you have a confirmation, you write the outcome in a document or in this tracking tool so you can easily recall the conversation and know how to verify that the story is done.
You can read all about it in Mike Cohn’s book “User Stories Applied”. Mike Cohn is a great practitioner and expert in the “user stories” area. I can’t recommend you enough to go to his website called Mountain Goat Software. You can find all the links below.
So this is how we come from Kent Beck stories in XP and arrive at the user stories we use today.
Adding the word “user” to the stories helps bring our attention to those for whom we are making the products. This can help clarify why “As a developer, I want” template can be accurate only if our end users are developers.
And that’s the story of User Stories.
It is introducing storytelling to your product creation. Stories can be written down using the template to make sure we don’t miss any important information but it is, of course, optional. What counts is that the Product Owner and the team, who will build the product, have a shared understanding of the goal they want to achieve.
Useful links:
- Kent Beck
- Mike Cohn´s blog called Mountain Goat Software
- Jeff Patton
