One of the things that often happens when the product
owner is technically savvy is that they start writing solution stories. That
is they specify how something should be done technically rather than
what should be done.
For example here is a story that states specifically how the task should be
Partition the customer history table horizontally
This story has been written by a customer
who either knows a lot about physical database performance tuning or has talked
to someone who does (or a least someone who tossed out a possible solution).
A better story that gets to the real
business need (performance) is:
Ensure that saving updated customer
information takes no more than 2 seconds on average
By knowing what the need is the developers
can look at the whole system to see why saving the customer is taking longer
than 2 seconds. This gives the developers latitude on how to solve the problem
rather than boxing them in. In this particular case the real solution was fixing
some logic in the trigger and adding an index.
What Make a Good
Bill Wake has an article on the
characteristics of a good story. He uses the acronym INVEST:
||Stories are easiest to work with if they are
independent. If they are independent we can schedule and build them in
any order. This allows us to select stories with the highest value
without worrying about all the expensive, low value dependent
||Negotiation is a key ingredient of agile development.
Remember that agile methods are typically scope variable. That is the
time line is fixed (iteration length) and the quality and scope are
varied. A story is a placeholder for discussion. We need to be able to
split, combine, tweak, clarify, etc stories at any time.|
||Stories need to have real business value to the
stakeholders. Typically this is the customer although there are other
stakeholders (including the development organization). I like to see all
stories expressed in ways that the primary stakeholder can understand
the value provided by the story. The definition of "value" can vary
somewhat from project to project and organization to
If a story can't be estimated then the customer
can't derive value or assign a priority to it. We don't need a
precise estimate or a guarantee that the estimate will never change. But
we do need a good enough estimate that is as accurate as current
Having small stories is a result of estimable and
negotiable. The larger the story the harder it is to estimate, the less
flexibility in negotiation. Each team has a "right size" story which
tends to be in the several hours to several days ranges (in ideal time).
Stories larger than this tend to fall into the "I don't really know"
Stories need to be testable, otherwise how do you know
the story is complete?
For more info on how to write better
stories see Mike
Cohn's book User
Stories Applied or look at the sample
Aren't there Any Exceptions?
Of course there are. Most projects have constrains of some kind which are
technical in nature. I.e. "Must support Oracle and MySQL" or "all logging will
use our custom Log4Net appender". These are definitely solutions, but generally
apply to all (or most) stories so I track them separately. I've heard of others
using different colored cards to visually indicate the difference between
feature stories and constraint stories. I also like to make a note on my feature
stories if there is some particular reason to pay attention to a constraint, at
least until the team gets a feel for where the constraints apply.
Solution Stories in the Wild?
What are the best examples of solution stories from your experience and how
would you rewrite them to be "real" stories?
Agile principles at work
So which agile principles are at
work in correcting this smell?
- Developers create & estimate tasks
- Developers self select tasks
- Customers write good stories