Deliver value – but how do we know?

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 if we are delivering value, if 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. 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 total the number of value points, (let’s just assume they total 250), we can distribute this additional revenue to each story ($1mm / 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:

Screen Shot 2013-03-28 at 10.00.52 AM

 

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.

Screen Shot 2013-03-28 at 10.03.52 AM

 

Now we are at iteration 13, and you can see that our value delivery has plateaued. If we continue work on this project, will we continue to ass more value than it costs?

Screen Shot 2013-03-28 at 10.06.50 AM

 

Another 5 iterations or 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!

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, right?

How does your organization measure value delivery – or does it?

Leave a Reply

Your email address will not be published. Required fields are marked *