Reason Based User Stories

The traditional format of a user story is “As a <role>, I want <goal/desire> [so that <benefit>]”.  For example, “As a billing officer, I want to search for unbilled completed orders so that I can bill the customer”.

Now there is some debate as to how important the <benefit> clause is in the user story.  In the above example it seems kind of obvious that the benefit is the ability to bill customers, and that is a good thing.  Some stay that it is so obvious that it can just be omitted.  Others argue that the <benefit> clause is the most important part of the user story and it should be stated first.  That format is “In order to <receive benefit> as a <role>, I want <goal/desire>”.  In this example it would read “In order to bill customers as a billing officer, I want to search for unbilled completed orders”.

The <goal/desire> clause of the user story is the really difficult part to get right.  There is a real art to this.  You are describing a desired solution (i.e. a requirement), but it must be stated in a way that allows for flexibility and out-of-the-box thinking.

For example let’s examine if the user story was restated “As a billing officer, I want unbilled completed orders to be highlighted in red”.  This is much more restrictive than the first statement.  This really binds the hands of the developer, product manager, or UX designer.  Before anyone can suggest alternatives, they have to convince the person submitting the user story to throw out they story in its current form, go back to the drawing board, and restate their requirement in a wording that is more flexible.

Even my original example can be too restrictive.  Is manually searching for unbilled completed orders the best solution?  How about emailing a these orders directly to the billing officer?  How about automating the billing process so that there is no need to search for unbilled completed orders?

I believe it is nearly impossible to get the goal/desire clause of the user story to be flexible enough to allow for a truly open discussion.  Therefore, I advise against trying to use this format as a starting point.  My preferred process for developing a user story is as follows.

I find when creating a user story, or any activity, the best place to start with the reason.  It is critical that everyone knows why something is worth doing before doing it.

The reason should be broken into two parts: the problem and the impact to the business. 

The problem statement is usually fairly easy to collect.  This can be done listening to the user’s gripes as they are doing their job or “at the water cooler”.  The problem statement that is written in the user story can usually be done verbatim from the end-user. 

The next step is for a business analyst to assess the impact of that problem on the business.  The business analyst’s work results on assigning a value or benefit to the issue.

After the business analyst drafts the impact statement, it is important that this is reviewed (i.e. tested).  The end-user and their managers submitting the problem statement should review the analyst’s impact assessment to ensure there are no communication errors.  The problem and impact statement are the first milestone in creating a user story.  With this work done it can be entered onto the backlog.

So the impact statement serves the same purpose as the benefit clause from the traditional user story format.  However the formats are very different.  The reason format attaches a real end-user’s problem to the benefit clause, whereas the traditional user story format attaches the benefit to a goal or solution.  The reason needs to be able to stand on its own, independent of solution.  This allows the end users and business analysts to discuss the value of the problem without the potential solutions biasing that discussion.  It also gives the business a firm footing to start on before evaluating potential solutions.

With the problem well defined, the next step is for the business to seek multiple solutions.  These solutions should be sought from both internal employees and external vendors.  Both high and low tech solutions should be welcome.  The business can then evaluate each solution for how well it will solve the problem.  Estimates can be gathered for the most promising solutions.  Often multiple solutions will be chosen to be implemented to cover any gaps or to provide redundancy in the system.

So let’s apply this methodology to an example problem. 

Problem: Some customers are not being billed for their completed orders.

Next we attach an impact statement to the problem.

Impact: Missing billing opportunities have been estimated at $50K per month of missing revenue.

Then we can start collecting solutions from a variety of people.

With the suggestions collected the business people can analyze how effective each suggestion would be at solving the problem.  Sometimes seeing all the various solutions can lead people to more solutions.  For example, “As a Developer, I could change the software to encourage the Order Filler to click the Bill button”.

Rejected solutions and be crossed off.  Estimates can be attached to each solution.  Approved solutions can be assigned.  The final reason based user story card would appear as follows.