A team I work with estimates User Stories on a relative Story Point scale based on the Fibonacci series. We actually used the Mountain Goat voting cards to implement this. There has been a little controversy lately about “technical” stories. As far as I can tell, these are stories that do not directly affect the functionality of the software. An example might be a technical prototype to evaluate the suitability of a database for a particular piece of functionality.
The non-techies believe that these stories should be estimated as 0 points as they add no “business value”. I have a couple of problems with this:
- I have yet to hear a definition of “business value”
- The purpose of Story Points is to allow the team to estimate how much work is required to do a job, not to indicate the “business value”
We know that we estimate Story Points so that we can look at the team’s Velocity and then work out which stories to put into a sprint. We also know that we use estimates to allow the rest of the business to take a longer term view of when a feature or product might be ready for release. Story Points are a measure of work, NOT business value (whatever that is).
As an aside, I would also dispute that technical stories have no business value. In the example above, selecting the correct database for a job is crucial. Imagine that we are looking at implementing a transaction system that needs to process 1,000 transactions per second. The team only has experience of Microsoft Access. Since there is no “business value” in creating a prototype for the technical story, the team decides not to do it. Consequently the team creates software that will never meet the non-functional requirements. Clearly here the technical User Story has large, critical business value.
Back to Zero Point Stories! The problem with these stories is that they deliberately mislead the business and cause unreasonable expectations to be made of the team. A team with a zero point story in a sprint will not complete all of the other stories in the Sprint because the zero point story will take work. So why mislead the business? Why not just estimate the technical story in the same way as any other story?
The argument of giving technical stories zero points because they have no business value is also flawed because Story Points are not a measure of business value – the priority of a story is! If the business wants a different measure of business value then the Product Owner should relatively estimate the business value of a story separately from the Story Points.
So, my recommendation is, if you want to be as accurate as possible in your estimates for Sprint planning and reporting to the business, estimate EVERY story, not just the stories with (the mythical) business value.