Story points vs value
In agile projects, we measure progress with Story Points. Compared to estimates we used before, like man.days, this tool is very powerful for saving us time. First because story points relative estimates, we save the effort of estimating every single piece of work. Secondly by using scales like the fibonacci suite (personally I would even simplify by using a scale like 1-3-10 for dev, and add something like 30-100 for later epics). It’s surprising for people that discover this, especially for business people or managers that don’t understand that we don’t know precisely where we’re going. But that’s reality, and using a widely adopted tool is a good opportunity for explaining it.
But I realize there are always a few things that are unclear to people that discover story points. It always takes a bit of misunderstanding and time to explain.
First… the fact that story points are relative estimates. In the projects I worked, I called them potatoes to make clear that there is no reference or unit to this metric apart from potatoes.
More important, we don’t necessarily realize what we measure. The first reflex, of course, is to estimate effort. That’s right. But then, we insist on producing business value. Depending on projects, we can even choose to get rid of everything that has no business value in the estimates, like defects or technical developments. As a matter of fact it’s what I did in my last projects because features were always the absolute priority and we couldn’t prioritize necessary technical work. I’m not proud of this situation, but when everybody doesn’t play the game of transparency… that ‘s another trade-off that needs to be adopted.
Anyway, when we begin talking about business value, what we measure with story points is not clear. A point is something we earn, but story points only measure costs, effort. In addition, we only estimate and measure development effort. Talking about Development Effort Potatoes would probably be more clear.
Now that we have the estimate, we need to balance this with business and technical value. We often talk about adding business value. It’s often not enough and difficult to evaluate, because many parameters like due date or risk must be balanced, so I won’t talk deeply about it. David J. Anderson’s approach is probably the best: instead of having a single number, he proposes to simplify the product owner’s job by giving him the right level of transparency from the production line, and allow to answer a basic question like “now that we can take a new task in the system, knowing tasks usually take X days to get out once they get in, which one to you want to see done in X days?”
And one thing’s missing. How can we make sure that we maintain a constant pace? Mainly by keeping a constant quality while developing. This is guaranteed by tools like tests and CI, but also and mainly by making sure that the quality of the code remains at the right level. Saying that we refactor while coding is not enough. We sometimes need bigger and specific refactoring sessions. And we always need to balance code quality and speed. When we choose to sacrifice quality, we accumulate some technical debt that has big chance to decrease the speed at some point, and we never know if and when it’s gonna happen. So we need to make this choice clear. For example, if we add a technical value besides an estimate to the story, everybody sees whether we accumulate some debt by choosing a lower cost.
Finally, I wonder what Story Points, or Development Effort Potatoes, mean in Kanban. You can know how long an item that comes in will take to get out, using lead time statistics. You can evaluate how long an item that is not coming in yet will take to get out by using throughput. If you produce 5 items per week with a lead time of one week, and your item is the 10th in the backlog, the time it takes to get out is: total time = lead-time + backlog size / throughput. In our case, 3 weeks. Easy when all stories take the same time or use the same quantity of throughput. But when you want to define the size of the story from its business value, well… size variability will not be constant. So you need to refine this formula. Probably by using something that is close to Story Points. But as we said, Story Points, as used today, only consider development effort, which is only a part of the system. Well… I hope I have more to say about it when I experiment a little more on Kanban. Hoping that things are simpler than they look, and that variability can stay low enough, so that we can use this simple formula.
Hope to get back soon on this topic. In the mean time, if someone has some experience to share, don’t hesitate to help.
AAAgile 
Estimating is hard to do well. Keeping stories short helps a lot. If you can’t get the story size down to single digits, it’s too long.
You’re also right that there is no relationship between business (or technical) value and story size — none at all. The PO needs to determine business value and high-value stories should get priority, if possible.
Ultimately, though, time really matters. How many stories can the team get “done” in a 2-week sprint? That’s why tracking velocity is so important. It’s the only reliable way to predict future performance. If the team has never worked together before and has no velocity, estimates are almost worthless.
Hi Vin, and thanks for your comment.
Short stories are definitely the way to go. Big stories actually lead to never-ending stories, because they’re re-assessed in every iteration. However, keeping stories short for keeping them short can also lead to getting away from business value. If you don’t deliver useful features through all stories, this can also lead to useless modules being implemented but never finished. So yeah, I agree, estimating and splitting up the work, are complicated tasks.
Of course, I agree performance tracking is important, at least for estimating what can be released when. I wasn’t saying we should get rid of story points, but rather that the word could have been clearer, as there several kinds of points for a story.
Just a comment about business value. As I said, defining a business value is not as easy as filling out a single number in a form. Mack Adams wrote an interesting and more complete post about this: http://false-deadlines.com/?p=267.