How to measure value? Part 4

Apr 28, 2016

Capgemini

Relative weighting

In Part 1, Part 2 and Part 3,  I explained Theme Screening and Theme Scoring. In Theme Screening we added a weight and made the scoring more relative.

Relative weighting takes the weight factor of Theme Screening to another level and adds the teams estimate to the equation to make a new ranking within the Product Backlog.

Consider the Backlog we have been working with so far:

In Relative Weighting we look at the following per theme:

• What is the impact of implementing this theme scored from 1 to 9.
• What is the impact of not implementing this theme scored from 1 to 9

We add these two values together per theme and this is the “Value” of the theme.

Then we determine the relative estimation per theme. This is the “cost” of the theme.

Both these need to be normalised to make it usable in the future. After all, a backlog is not a fixed list. We can do this by making the “Value” and “Cost” variables into percentages. Add up all the values and all the costs and determine per value-variable and cost-variable what this represents as a percentage of the whole.

Then we divide the Value percentage by the Cost percentage. This represents a very pure ROI number of the theme. This ROI number we can use to rank the Theme in the full list.

What I like about this way of determining value is that it actually relates it with the costs as well. Mind you, this does mean that you have to have sessions with your development team to discuss the Theme before you can rank it in your list. To be honest, I expect the Product Owner to involve the team anyway in the Backlog Refinement sessions every week.

Let’s look at the Matrix again:

Considering the highest ROI gives the following ranking:

Looking back at the different methods to calculate value I have a slight preference for Relative Weighting when I consider the full ROI focus I expect a Product Owner to have. It is still a tool and Agile considers tools to be important only if they support interaction.

What tool you choose is up to you as “value optimizer”. Make sure that it matches your environment and product.

You could also use more than one tool. I can imagine that the first setup of a Product Backlog when you have not selected a development team yet is best helped by Theme Screening or Scoring. Without the estimations of the team the ROI calculated in Relative Weighting is too unsure. At least determine with your stakeholders what is important to get ready for the new team first. But involve existing or new to form development teams in your determination of Product Backlog items.

For this technique there is also a tool on Mike Cohn’s site

In the past 4 blogs I have given you some tools. I would like to remind you of the first value of Agile:

We value: Individuals and interactions over processes and tools
agilemanifesto.org

The use of tools should not interfere with your work as Product Owner with your team(s).

You as Product Owner are accountable for Return of Investment, most of the time with the research that you do and the stakeholders you work with you get a feeling of what is value for you and your product. With the tools I have given you it is easier to quantify this feeling. Don’t ignore your feelings though. The best result from Agile product development comes from focussing on the outcome as opposed to the output. Outcome is usually user satisfaction not short term profit.

About the author

Sogeti Labs

SogetiLabs gathers distinguished technology leaders from around the Sogeti world. It is an initiative explaining not how IT works, but what IT means for business.

Comments