Are we burning the right thing?

Is our development effort aligned with the business?

Are we getting good value out of our development team?

Is our team working on the right items?

Are we on the right track to get more value out of the team?

Are we burning the right thing?

Product Managers get a severe headache when these questions bang-bang their minds. Our development teams are usually great and great teams can deliver great software, but when the software delivered isn’t of high value the Business (i.e. the Product Managers) will still not be happy!

Hence, customer collaboration is weighted more in agile. I encourage a tight alignment of the development team with the business.

We measure the business alignment using three metrics:
1) Return on Investment (ROI)
2) Internal Rate of Return.
3) Total Business Value Earned for every Story Point that is burnt.

Agile teams deliver visible results by calculating the ROI for Features and/or User Stories. The ROI can be calculated in two different ways:
1) by taking the actual monetary value of Features and/or User Stories.
or
2) by calculating a relative value of Features and/or User Stories.

I prefer the second way of relative value which is easier and more in line with estimation techniques in agile/scrum. In this approach, we can use an estimation technique similar to the one used for Effort
Estimation; to associate a number of Value Points (similar to Story Points) to a work item, for example using the Fibonacci range.
During sprint planning, we can pick one User Story (or a small set of Stories) to set the baseline for the value of a Value Point.

It is important to note that the Business Value should be estimated by the representatives of the
Business, i.e. the Product Manager, Product Owner (PO) and business stakeholders, and NOT the development team.

How to do it?
1) While creating a feature/story Business Representative (i.e. Product Manager or Product Owner) will put Value Points to the feature. We can use "Affinity Estimation" technique for the same.
2) If the feature is broken down in to stories and you are enthusiastic enough, then you can give Value points at story level as well. In an Ideal World (which usually does not exist), I would give Value points at story level, which will help to generate the sprint level metrics.

While generating the graph for the historical period, all the Value Points of the all User Stories can be accumulated to gather the Total Business Value Earned during that period. The ROI can then be calculated by dividing the total Value Points by the total Story Points.

Example:

Look at the above graph of Value Points Vs. Story Points. We see that the Velocity (i.e. Story Points per sprint) is increasing rapidly from sprint 1 to sprint 5 - a reason for celebration!? NO. If we plot the Value line and see carefully, then we understand that the actual value delivered by the team was going down from sprint 1 to sprint 5 - a matter of concern for Product Manager. Was the team really productive despite of showing a significant rise in velocity? It indicates that team was putting a lot and lot of effort on the items with lesser business value. After sprint 5, Product Manager must have taken some action which helped the Value line to go up. After sprint 5, the velocity came down, which needs to be investigated through Retrospective meetings.

Thanks to the combination of the Velocity Vs. Value graph where we can see that it is foolish to aim
solely at raising the Velocity when that means hurting the Business Value. That is why the Business Value should be taken into account when prioritizing a Backlog.