In my previous
post I described my feeling on why it is so critically important to develop
a good user story. However I didn’t go
into much detail on how that is done. I’m
going to cover that in this post. I’ll
start by looking at the classic “goal/desire” based user story formats,
followed by my own reason based format, then an example.
Classic “Goal/Desire”
Based User Story Formats
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.
Reason Based User
Story
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.
Example
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.
- As a Billing Officer, I could solve this problem
with better search tools in the software for unbilled completed orders.
- As a Developer, I could solve this problem by
writing a program to email unbilled completed orders to the Billing Officer.
- As a Developer, I could solve this problem by automating
the billing process.
- As an Order Filler, I could solve this problem by
remembering to click the Bill button.
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.
Problem: Some customers are not being billed for their
completed orders.
Impact:
Missing billing opportunities have been estimated at $50K per month of
missing revenue.
Solutions:
- As a Billing Officer, I could solve this problem
with better search tools in the software for unbilled completed orders. [8
story points, approval depending on success of solution#5]
As a Developer, I could solve this problem by
writing a program to email unbilled completed orders to the Billing Officer.
[Too large]As a Developer, I could solve this problem by
automating the billing process. [Too large]As an Order Filler, I could solve this
problem by remembering to click the Bill button. [Not testable]- As a Developer, I could change the software to
encourage the Order Filler to click the Bill button. [2 story points, approved for next sprint]