Consider the following scenario.

1. You’ve got two parts of the code base. One part is beautiful code, written TDD, used continuous integration, pair programming, well written stories were used to produce it, clear acceptance tests, all the good stuff. The other part is horrific, hardly any tests, when the build failed, you disabled the tests that failed, the stories were written as technical tasks, acceptance tests vague, etc.
2. You are asked to deliver two medium-value stories in the next iteration. One story is most done in the good part of the code base. The other story in the bad part.
3. Correspondingly, your estimates will vary according to the complexity of the code base – the story in the “good” code might be 5 points, the story in the “bad” code is 15. But the value to the business delivered is the same!

The point is, the amount of effort that you do (20 points) to deliver 2 medium value units, is actually not a measure of your progress. It’s a measure of your waste. The next iteration you might be able to deliver 4 medium value points, if they are all in the “good code” base! Same effort, twice the return on value. Software developers know this about well designed code bases combined with good engineering practice, of course. The point is about directly exposing the effects of bad engineering as it manifests itself as a barrier to progress.

What if you told the business instead, you’ll deliver x business value points instead? That is, your burn down and burn up charts don’t show story points of effort expended, but directly indicated value delivered. What impetus does this lead us to? Well, now we’ve got a direct measurement of story points over business value, which is the proportion of waste to value. The ultimate story is infinite in value and takes zero points to deliver!

I think this is not all; because it directly establishes the ratio of waste to value, it gives you an impetus to eliminate waste, that is, to practice good, professional, software craftsmanship of the type that Robert C. Martin talks about in the video I linked to earlier tonight. Software that allows you to change efficiently to meet new needs now becomes not an abstract principle that you must kick back at your managers every time the demand to see “more features” and less engineering, but becomes a direcly correlated measurement of productive output.

It’s not all plain sailing, for the really hard nut has to be cracked. How the hell do you measure business value in units like “points”? I don’t have a cheap and easy answer right for it right now. But I don’t think this very hard question should go unanswered. For me, it’s the missing piece of the agile software delivery puzzle. I’ve been asked countless times, to estimate effort on whole swathes of stories where I think it’s obvious that the business value is actually highly dubious – or at least cannot be quantified by the product owner. On one level, that’s fine, they pay the bills and get to set the priorities, but on another level, I think that having to produce a quantifier for the value will help the product owner focus their minds onto the outcome in a much better way.

And it enables them to directly see the correlation between bad engineering practices and the inefficiencies they engender. Those bad practices are certainly our fault for putting them in place, don’t get me wrong, I’m not shirking our personal and professional responsibilities in that regard. However reducing outside pressures will certainly also help by giving us a little breathing space to demonstrate with hard numbers the value of taking care with our craftsmanship. And it reports the thing the business are most interested in – the value you deliver.

If my post is a little unclear, forgive me it’s late at night as I write this. Better blog entry than code in the tired state I’m in!