Agile Process Smells: Solution Stories

Tuesday, October 11, 2005

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 completed (solution):

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 Story?

Bill Wake has an article on the characteristics of a good story. He uses the acronym INVEST:

I Independent 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 stories.

N Negotiable 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.

V Valuable 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 organization.

E Estimable
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 information allows.

S Small
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" category.

T Testable
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 chapter.

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

I	Independent	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 stories.
N	Negotiable	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.
V	Valuable	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 organization.
E	Estimable	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 information allows.
S	Small	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" category.
T	Testable	Stories need to be testable, otherwise how do you know the story is complete?

1 Comment