Putting Value First With The Reverse User Story

User Stories are a great way to translate your users’ needs into real tasks that your team can work with. They’re succinct, lightweight, and flexible. But what if you could make them even better by moving the "why" of the story to the beginning?

To understand how you can improve them even further, let’s start by looking at an example of a User Story…

User Story format

This format answers the important questions clearly, but it keeps the most important part of the story...the benefit...until the end. The benefit, or the “So I can…” part of the story, is how you ensure that your team understands why they are building this story and how it will contribute to your overall vision for your product. Without clearly stating this benefit you risk adding functionality that doesn’t move your product towards its vision.

Saving this part of the story until the end means that we ignore it or even leave it out completely. The result of this is that the benefit of the story is shortchanged.

Turning the Problem on Its Head

The Reverse User Story, on the other hand, moves this important clause to the beginning of the story.  This format, inspired by the Reverse Stand Up, recognizes that the benefit is the most important part of the story and therefore it should appear first.  Building on the example above, our Reverse User Story would look like this...

Moving the benefit to the beginning of the story forces your team to first think about the business value and resulting benefits of your work. If you’re unable to articulate a benefit for a story then this can be a warning sign that you don't understand the story as well as you thought you did. This may mean that the story still needs fleshing out or even that it may not be worth the effort required to bring it to fruition.

Finding Balance...Or the Zen of Release Management

Bringing the expected benefits to the forefront can also aide in long term exercises like Release Planning. For example, if the majority of stories selected for a release seem to have similar benefits then this can be a hint at the theme that’s emerging for that release. Alternatively, if too many stories have the same benefit then this can serve as a warning that you’re weighing the release too heavily towards one specific feature set while starving another.

Shifting the focus to the benefit can also help identify stories in the backlog that are duplicating value. Recall that one of the goals of Scrum is to optimize the ROI of the development team. To this end, if more than one story is accomplishing the same end goal then this can be an opportunity to drop a duplicate story in favor of another that may bring more value to the product.

Drawing in the Team

Bringing the business goals of the story to the forefront draws the team into the discussion.  This can even lead to the discovery of alternative approaches as to how those goals may be met.

For example, recall that the original idea of your story was to allow a customer to save items for later.  You'd assumed that the only way to do this was to make their shopping cart persistent.  But, perhaps someone on the team suggests instead providing a wishlist where the customer could store items for long term. This would result in the story being changed to...

So I can save items for later,
As a customer,
I want to add items to a wish list.

This change may even spawn additional conversations regarding the opportunities that the wish list could open up. Perhaps the customer could share their wish list with friends who are shopping for them.  Or, maybe they could even post them to their social networks. This would give you the opportunity to also capture sales from friends of the customer.  This could even happen when your original customer isn’t quite ready to buy an item themselves.

None of these ideas would have ever been suggested if the developers had not first been encouraged to consider the overall benefit they were trying to achieve rather than simply focusing on the action.

Putting This Technique to Use

Though a Reverse User Story has many advantages over the format it still may not be right for every situation.  Specifically, the classic format’s simplicity and broad adoption make it a good choice as a starting point for introducing the concept of User Stories to new teams.

But, if your team seems to be missing the bigger picture of the stories or is becoming mired in the details then this twist on the classic format may be just what you need to shift everyone’s focus away from specific actions and back to the overall goal of the product.