Blog

Why You Need To Jazz Up Your Boring User Stories

By William Baxter | Jun 20, 2016 |  Article,  Scrum,  Team
Trumpeter, jazz up Writing User Stories
This picture was found on Flickr under the Creative Commons license. Thank you, Jose Hidalgo for the great picture.

User stories are a staple of Agile practices. Most teams use the following standard three-clause template:

As a USER

         I want FUNCTIONALITY

         So that BENEFIT

Teams are generally successful at creating conversation around user stories following the prescribed format, especially if they add acceptance criteria and adhere to the (3Cs) (Card, Conversation, Confirmation). Many teams also work hard to endow their stories with the INVEST qualities. Using the template, the 3 Cs, and infusing with INVEST, create sufficient user stories. Passing. Maybe even a B. But how do you get to an A+ and does it really matter?

A Bad User Story

Most teams struggle to write compelling user stories that provoke vivid imagery and lively discussion. Why? Let’s look at a bad user story and show how to improve it.

As a shoe buyer

       I want to filter by style

       So that I can find the shoes I want to buy

This is so bland it gives you nothing to go on. What motivates the buyer? Does buying itself thrill them, or is that act a means to some other end? Do they really just want to buy, or are they after some other benefit?

Boring USER clauses

The worst case user clause literally says “As a user.” Why bother. Better to omit the clause altogether. It offers no insight into the user’s perspective and motivation as they interact with the product.

A good user clause tells you about the psychology of the user as they interact with your product. Is the user impatient, lazy, excited, pressured? What type of interaction do they have with the product? Providing both clues in a user clause brings a clear picture to mind. Let’s try it.

As a fashion trendsetter

       I want to filter by style

       So that I can find the shoes I want to buy

By replacing “user” with “fashion trendsetter” teams have more insight into the end goal for that specific user. What would happen if “fashion trendsetter” was replaced with “busy professional?” A fashion trendsetter is interested in finding the perfect shoe and may need more filtering options to help them find the exact pair they had in mind.

A busy professional may just want a shoe that fits minimal criteria: size, color, function.

Generic BENEFITS clauses

What does your user get at the end of the story? What benefit do they seek? It’s convenient to think that their benefit coincides with the benefit they bring to you, as we did in the original story. That’s lazy story writing. Even lazier is to omit the benefits clause completely, assuming that the functionality is the benefit.

Combat laziness with empathy.

Put yourself in the shoes of the user and ask what they want? In this story, our user sets trends. They want to be ahead of the fashion curve and need people to look upon them edgy. How about this:

As a fashion trendsetter

       I want to filter by style

       So that I can wear the new styles first.

With the improved benefits clause, the team can think about the best way to display the items according to a fashion timeline.

Non-negotiated FUNCTIONALITY

The functionality clause represents the scope of the story. In keeping with an Agile approach, scope is negotiated for each iteration, and this clause will change accordingly. You may end up with several stories with similar, if not identical, user and benefits clauses and functionality clauses that expand scope over the iterations.

In our example story, we can tailor the scope to our chosen user and benefits.

As a fashion trendsetter

       I want to filter by designer

       So that I can wear the new styles first

The term style can mean many different things. Therefore, let’s substitute a simpler selection of designers for “style” in the first iteration.

Why does this matter?

This final story is far cry from where we began. It’s lively. It conjures a picture of motivated interaction with our product in pursuit of a personal goal. This matters both for teams implementing stories and stakeholders following along as they do. The more compelling a story, the better the hooks for conversation. And it takes only a minimal investment in rewriting.

Rewrite your bad user stories with the following steps.

  1. Tailor the user clause to the persona–make it specific. The user clause should NOT have the word “user” in it.
  2. Ensure the benefits clause speaks of the persona’s motivation.
  3. Set the scope with the benefits clause.

Following this order lays down markers around the user and their goals first, and then negotiate the scope that connects them. Investing just a little time in rewriting your user stories will lead more lively conversation and a richer common understanding of what you are building and why. Creating that shared understanding, after all, is the ultimate point of user stories.

 

This post is a re-write of “User Stories Outside In,” a post I wrote in Fall 2015. We added more information to further explain concepts.

Leave a Reply

Your email address will not be published. Required fields are marked *

< Back