Better scrum user stories: save the solution for the spec

In the world of Scrum the user stories are at the heart of everything that’s added to the software: it’s how you break down the product strategy and requirements into discreet, develop-able chunks. We build software for our users, so it makes sense that everything that’s added to or taken away from the software is expressed in terms of a user need.

The Scrum textbook recommends the following standard form for a user story:

– As a user, I want to do {thing} so that I {reason}.

The trick is to focus the story on what the user really wants, not how you plan to solve that need. You need to keep the solution out of the story.

A couple of examples:

“As a user, I want to see my favourite places in a list so that I can find the one I am looking for.”

What’s wrong with this story? It is not a story about a user need; it is a specification for a solution. Does a user really want to see their favourite places in a list? Or do they just want to see their favourites? Is a list the only way to solve this need?

How about: “As a user, I want to find the favourite place that I’m looking for, so I can see information about it.”

Another example:

“As a user, I want to see Public Transport lines on the map.”

Do they? Or do they want to know where Public Transport lines run? Is putting them on the map the only way to do that?

How about: “As a user, I want to understand where Public Transport stops are in my city, so I know where to go to get the next train.”

Why is it important to keep the solution out of the story?

The User story represents the problem that the user wants to solve, to which you and your team need to find a solution. The steps to finding a solution are understanding the problem, brainstorming/investigating possible solutions, possibly in conjunction with benchmarking of competitor products and user research, then selecting a solution and specifying how that solution will work. When the solution is already embedded in the story, you spring over the first two steps, which not only means that you’re not looking at the problem broadly enough, and you will potentially miss good, new or innovative ways to solve the problem, but you’ll have no data to justify that the solution you chose was better than any other.

Write stories that focus on needs, and save the solution for the specification.

Advertisements

About Will

I'm Will. I'm a product creator, Scrum and Agile advocate, web enthusiast and change instigator. I work for Nokia and I am the Product Owner of Nokia's web social location platform, maps.nokia.com
This entry was posted in Scrum. Bookmark the permalink.

2 Responses to Better scrum user stories: save the solution for the spec

  1. Pingback: Better scrum user stories: Split stories horizontally, not vertically | Will's Blog

  2. Pingback: Better SCRUM User Stories: Connect the story with the real user value | Will's Blog

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s