Mike Cohn once said "Product Owners are often given the vague and mostly useless advice "Prioritise on Business Value" " and he's right.
If you read a scrum guide or a paper on prioritisation, or indeed many of the learned texts on Agile, they all seem to fall into a grey area around what business value actually is. They will potentially give you reams of advice on prioritisation methods, however these can only be applied once you understand where your value lies.
In reading around this I found Emergn stating in VFQ (value, flow, quality) that you can prioritise effectively if you can measure (or estimate) Value, Cost, New knowledge and Risk. The thing is; the first two are in cash (£/$) so what if the purpose of your project is to improve customer relations or company reputation?
Thoughtworks have had a good go at this one and in a paper by Paul Ellarby which I enjoyed; it proposes the way to value measurement is to create the four elements below:
- #1 Develop your organization's “value language”
- #2. Understand the value-cost of each portfolio down to the feature level
- #3. Allocate value points across all capabilities
- #4. Track value vs. cost for each iteration
This has some good guts behind it and the concept of "value dials" for a range of elements important to an organisation seems well thought out and helps us "find" our value. It also makes the point that those value elements may or may not map to the bottom line so helps with non-financial goals. My observation though is that this concept seemingly needs adopting at a Corporate level as a framework and then cascading down all projects or it doesn't seem to work properly. In organisations that are not in a position to transform their own governance but still need to understand value per-project/in-project there still seems to be a bit of a gap.
I then drifted in to a bit of a twilight zone and found myself thinking "well if you can measure value, then you can define value" - and an Agile colleague introduced me to the book "How to Measure Anything - finding the value of intangibles in business" by Hubbard. I managed three chapters of this book, and the anecdotes about how you can measure complex things with simple means was pleasant enough. Apparently you can estimate the scale of an atomic bomb blast by scattering confetti into the resultant wind, and seemingly you can estimate the number of piano tuners in Chicago with relative ease.
What this book didn't really do for me though was unlock the challenge of finding what is valuable versus what isn't, and therefore I was back to square one again. Through conversations with more Agile colleagues I now have a quick recipe (credit to Nik Silver & Laurence Wood):
1. Run a Value Mapping workshop with stakeholders (real ones) using a wall like this:
- Use post-its to capture things that feel relevant or valuable to the project or outcome, and categorise them above - you may end up with the same items in both swimlanes but in different categories (duplicate post-its as appropriate).
- Discuss the conflicts and shared values across the canvas.
- Create a very small group (sub-set) of the post-its that represent what is truly important/valuable (in theory this will only come from the left-hand side)
- Agree that the remaining post-its are not truly important and therefore should not form the a value statement for the project/outcome or bias any later prioritisation.
- Photograph both of the above!
2. With the stakeholders above, write a single value statement for the project/outcome.
- A value statement is a very brief description of why something is being done. It should contain some visible business value, this can be financial or non-financial. It is very helpful if this is described as an outcome.
- TIP: Try writing a value statement as a User Story and see what "So That" says.
3. Agree a Value Measure for the Value Statement.
- A value measure describes some tangible way of detecting a change. It can be financial, emotional, or physical/environmental. It could be a bank balance increase, or simply the number of smiling people in the office - yes it can be that random.
- TIP: Write your "user story" Value Statement, then add line 4 “As measured by:” ..your Value Measure
Do not worry about the mechanism or feasibility of how to actually measure it.
If all has gone well, then you now have a clear definition of what is valuable to the activity/project/outcome being considered, and you have an idea as to what could be a measure of it (not how to measure it). As Hubbard suggests; anything that affects any type of change whatsoever can be measured (even things like love, happiness, and reputation), otherwise it did not affect a change.
You should now have a "thing" which you can publish and measure against; "Are we working towards our value statement" "Does this activity contribute to our value" and more pertinently when it comes to prioritisation; simply "Which of these two do we think will contribute the most to our value".
Whilst it may seem silly; a conversation about whether a hundred balloons or a massive cake would bring the most happiness to an office (as measured by smiles) can usually divine an answer one way or another. You can use this "either-or / hotter-colder" test to a whole backlog and you don't ever have to actually count the people smiling. :)
