Scrum by Example – How to Deal with Bad User Stories as a ScrumMaster

It is common in the early stages of Scrum implementation for there to be misunderstandings about what User Stories are for and what makes them useful. A ScrumMaster’s task is to be able to help the Team and Product Owner when they are faced with ineffective User Stories as they go into Sprint Planning.

Dramatis Personae:

Steve – a ScrumMaster and the hero of our story
Paula – the Product Owner of Steve’s team

A Bad User Story Helps No One

Steve is preparing for tomorrow’s Sprint Planning session. He asks Paula to show him the Product Backlog and she sends him a spreadsheet. Besides how difficult it is to read anything in this format, he’s shocked by how poorly the User Stories are formulated:

• As a user, I want to search Smallestonlinebookstore.com to find some books
• As a user, I want to buy the book that I’m currently looking at
• As a user, I want to search using the author’s first and last name fields along with the title field
• And so on…

Reading through, he also realizes that the Development Team hasn’t seen these stories or discussed them with the Product Owner yet.

Steve panics; the team can’t possibly have a Sprint Planning meeting tomorrow if they have never seen the User Stories at the top of the Product Backlog.

A Good User Story Is All About Users’ WHY

There are three central problems with the kind of User Stories you see above:

1. No Clear Why

A User Story is essentially the outcome of a conversation the team has with themselves and the Product Owner, in which the Product Owner explains the context for a desired product feature and what kind of value it is meant to give the user. This should be followed by a discussion about how to best deliver that value.

Paula’s User Stories identify a user and the desired features, but lack any explanation of how these features benefit the user – the essential reason WHY the feature is necessary in the first place.

This is critical because a good “why statement” is important not only for effective prioritization of the Product Backlog, but it also helps the team consider different approaches beyond the original intention.

As an example, take the first User Story: “As a user, I want to search Smallestonlinebookstore.com to find some books.” Conventionally, a User Story like this should have a “so that” clause at the end, explaining why. So, as a step towards making this a good User Story, we can begin with adding to it:

As a user, I want to search Smallestonlinebookstore.com to find some books so that I can save time by quickly locating what I am looking for.

In this instance, the Product Owner and the Team have determined that the speed at which a user could find a specific book is important, explaining why the search feature is needed and what benefit it provides. This User Story still isn’t complete, but this could be a good place to start a conversation between the Product Owner and the Team about the feature.

2. Too Broad and Generic to be Useful

The above User Stories are all much too broad to be implemented effectively. This is evidenced by a total lack of descriptors of either the feature or the user. Who exactly is the user in any of the stories? Are they all the same user? Are they all different? In the case of “As a user, I want to buy the book that I’m currently looking at,” how might they want to buy that book? Perhaps a one-click buy and delivery system? Do they want it as a paperback, trade paperback, hardcover, e-book? We don’t know.

User Stories that can be interpreted in all kinds of different ways are not useful. If you attempt to proceed with working on a Story likes this, it would be unsurprising if miscommunication were to happen, resulting in neither the Product Owner nor the customer having their expectations met by your product.

To be specific and focused, a good User Story needs to have a few characteristics:

• It must have a clearly defined user or persona (e.g. frequent book buyer; guest).
• It should be specific to the user’s context and the benefit they desire.
• It should be clear what the user wants to achieve.
• To ensure it can be completed within the Sprint, a single Story should be restricted to what can be completed in 2-3 days by the Team.

To improve further on the “save time by quickly locating…” User Story in Problem 1 and make it specific and focused, additional details need to be added:

As a frequent book buyer, I want to search Smallestonlinebookstore.com to find a book using the author’s full name so that I can save time by quickly locating more titles by the author I just finished reading. (3 Story Points)

Now the User Story tells us something about the nature of the specific user, what kind of outcome they want from the feature, and details about why speed is a desirable benefit for them. It also now has a points estimate associated with it, indicating how much work this story will be for the Team.

3. No Conversation with the Team

Perhaps the most serious problem with Paula’s User Stories is that they have all been written by her, the Product Owner, in isolation. How can the Development Team effectively plan the next Sprint if they haven’t yet seen, let alone discussed, the most important User Stories with the Product Owner?

Remember: A real User Story is one that comes from a conversation between the Team who will do the work and the Product Owner who is responsible for the vision for the product based on customers’ desired outcomes. Since the Team has never seen these items before Sprint Planning, they categorically can’t be real User Stories. It also means that if there were any Story Point estimates attached to these Stories as to how much can be accomplished in one Sprint, they aren’t going to be meaningful because only the Team can estimate the amount of work needed to complete a feature.

The Right Way to Create User Stories

Before a specific feature is ever built, there should be a discussion between Product Owner and the Team about what the user expects the feature to do and why it’s wanted. The understanding generated by this discussion is then written down as a User Story. Ideally, the conversation should focus on what problem the user wants the feature to solve. This process is the core of Product Backlog Refinement.

What To Do When You’re Faced with Bad User Stories

So what options does Steve have as he sees unclear and unspecific User Stories that the Development Team have never seen, let alone discussed, on the Product Backlog for tomorrow’s Sprint Planning session?

• He could work the rest of the day with Paula to rewrite and split the stories, although this still won’t engage the team and get accurate estimates on each User Story. This also sets a bad precedent of having to work overtime.
• He could cancel the Sprint Planning session and delay the start of the Sprint on the basis that the backlog is not ready to be used in planning. While this isn’t the worst course of action, especially given that Paula is new to Scrum and is trying to do the right thing, cancelling Spring Planning at such an early stage in Scrum implementation tends to send an extremely strong negative signal to everyone, especially senior management.
• He could turn tomorrow’s Sprint Planning meeting into a Product Refinement session, allowing Paula and the team to collaboratively rewrite and estimate the Stories. Once that is done, they could then proceed with a Sprint Planning meeting.

Steve suspects that the last option – backlog refinement followed by Sprint planning – is the best course of action, but he wisely chooses to first do what is almost always the best thing a ScrumMaster can do when faced with a difficult decision: ask the Team.

Steve sits down with Paula and the Team to discuss the challenges that he sees.

• He focuses not on the mistakes made, but instead on the Product Backlog and what makes a good User Story;
• He explains the current state of things to both Paula and the Team. Given that the meeting is the next day, he asks the team what options they see, describing all the options he thinks they have, and then finally,
• He asks the Team to decide what the best course of action is.

These actions demonstrate that Steve is focused on helping grow the autonomous decision-making capacity of the Team, while facilitating better communication between them and the Product Owner. Even if they make what Steve believes to be a less-than-optimal choice, they will get the critical opportunity to learn from any mistakes they make and grow from them. At the end of the day, this is what being a great ScrumMaster is all about.

The Team agrees that the next day should be devoted to doing Product Backlog Refinement, with the formal Sprint Planning following shortly afterward. Armed with an accurate and effective backlog, the Team proceeds with their Sprint.

Scrum by Example is a narrative-style blog series designed to help people new to Scrum, especially new ScrumMasters. If you are new to the series, we recommend you check out the introduction to learn more about the series and discover other helpful articles.

Mark Levison

Mark Levison has been helping Scrum teams and organizations with Agile, Scrum and Kanban style approaches since 2001. From certified scrum master training to custom Agile courses, he has helped well over 8,000 individuals, earning him respect and top rated reviews as one of the pioneers within the industry, as well as a raft of certifications from the ScrumAlliance. Mark has been a speaker at various Agile Conferences for more than 20 years, and is a published Scrum author with eBooks as well as articles on InfoQ.com, ScrumAlliance.org an AgileAlliance.org.