User Stories Outside In

User stories are a staple of agile practices. Most teams use a standard three-clause template resembling this

As a USER
I want FUNCTIONALITY
So that BENEFIT

Teams frequently successful at creating conversation around user stories, especially if add acceptance criteria and adhere to the (3Cs) (Card, Conversation, Confirmation). And many teams work hard to endow their stories with the INVEST qualities. Nevertheless, most teams struggle to write compelling user stories, stories that provoke vivid imagery and lively discussion. Why? Let’s look at a bad user story and show how to improve it.

A bad user story

Here a bad user story. Have you seen this type before?

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 in interacting with your 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 trend setter
I want to filter by style
So that I can find the shoes I want to buy

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 more lazy is to omit the benefits clause completely, assuming that the functionality is the benefit.)

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. They want people to look upon them as bleeding edge. How about this.

As a fashion trend setter
I want to filter by style
So that I can wear the new styles first

Non-negotiated FUNCTIONALITY clauses

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. The term style can mean many different things. For the first iteration, let’s substitute a simpler selection of designer for style.

As a fashion trend setter
I want to filter by designer
So that I can wear the new styles first

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. And that in turn provokes better conversation around the story.

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 following the pattern we used here. Start with the user clause. Then focus on the benefits clause. And finally turn attention to the functionality clause. Following this order helps you lay 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. And creating that shared understanding, after all, is the ultimate point of user stories.

comments powered by Disqus