We talk a lot in the Agile world about “delivering value”. It is the focus of almost every Agile workshop I have attended, is a catchphrase in the Agile world, and is the focus of Agile projects. But:
- How do we know we are delivering value, and
- How do we know we are doing the right thing?
When we plan an Agile project, one of the things we do is assign point estimates (tee-shirt sizing, team estimating, etc.) to provide a framework to understand the relative complexity of getting a story to “done”. We also prioritize these stories so that we work on the “most important” story first, leaving the least important stories until later in the project. These are a good start, but we need to go further.
One technique I use is to assign “value points”, which, like estimating points, are relative measures of the value returned by each story. But what do these points mean?
All projects should have a financial aspect to them, be it increased revenue, cost of entry into a new market, regulatory exposure, or something similar. This financial benefit should, of course, outweigh the cost of the project, yet I see projects dragging on and on, eating more of the potential profit from each project. How, then, do we know when to stop spending?
When we assign value points to each story, we can now allocate financial benefits to each story too. Let’s say our project is worth $1 million in additional revenue. If we sum up the number of value points (let’s just assume they total 250), we can distribute this additional revenue to each story ($1m / 250 = $4,000 per point).
We also can fairly easily calculate the fixed costs for the project. For example, the size of the team has a definite cost, any tools that are purchased, and so forth. From this, we can calculate the cost of each iteration.
Remember that the unit-of-work for an Agile project is NOT time but stories, and we can easily measure when a story is “done”. So now we can plot the value delivered in each iteration (value points per story x $4,000), and the cost of delivering that story. We should get a graph like this:
You can see that we have worked for 8 iterations, delivered about $900,000 in value, and have consumed approximately $450,000 in cost. Not a bad return on our investment, so it makes sense to proceed.
Now we are at iteration 13, and you can see that our value delivery has started to plateau. If we continue work on this project, will we continue to add more value than it costs?
Another few iterations of decreasing value, and now we are running a deficit. It is costing more to deliver software than these additional features are worth. We should have stopped several iterations ago!
Remember, these value points are estimates – we have no way of tracking the real impact of this software until it is released (which you may well be able to do with Continuous Delivery techniques). And like every metric, these will not solve any problems. Rather, they highlight concerns in this project and direct us to investigate further. But if we do not measure our value delivery, we never have an opportunity to ask these difficult questions until after we deliver. And then, for all intents and purposes, it’s too late. Right?
How does your organization measure value delivery – or does it? If it does measure value, what metrics does it use? If it doesn’t, what repercussions has that had? Comment below to get the conversation started!