Skip to main content

A "Qualitative" Formula for WSJF?

In this series of blogs we have been examining the use of Cost of Delay as a way of understanding ordering work - either from a quantitative approach using estimates for value, urgency, duration and/or size, or from a qualitative approach, such as the use of Delay Cost Profiles [1], Risk Profiles [2,3] or Value Size matrices [4]. The SAFe definition of WSJF is something of a hybrid, since it uses a formula, but a formula that has only "qualitative" value at best. Here is their definition [5]:



The 4 terms are determined by Planning Poker estimation using a Fibonacci scale (usually 1 to 20). The work items are ordered according to the formula following an estimation workshop. While this formula cannot provide a true quantitative analysis for ordering items to maximise value, some consultants using it have said that is a useful technique for the discussion it engenders among stakeholders. Once the numbers have been generated the items ordered, re-ordering to a better order is straightforward because of all the discussion that has preceded this point. Needless to say, I strongly disagree with this. While the discussion is necessary for a quantitative or qualitative approach, creating a spurious anchor from numbers which cannot be meaningful will lead to cognitive bias rather than better ordering.

Why can't the above formula provide meaningful answers? For 2 reasons:
  1. Dimensionally the formula is inconsistent
  2. The terms are not estimated on a proportional scale
These problems were addressed in Joshua Arnold's proposed modification to the formula [4] which rearranged the terms as follows:

"WSJF" = Time Criticality x (User-Business Value + Risk Reduction | Opportunity Enablement) / Size

Dimensionality is addressed, subject to the following assumptions:
  1. Time Criticality, τ, has units of the reciprocal of time (e.g. days-1). In other words an option expiring in 2 months would have double the τ of one expiring in 4 months.
  2. User-Business Value and Risk Reduction | Opportunity Enablement are measured in consistent units, possibly using a weighting factor to translate the intangible values to the units of the tangible values
  3. Size is proportional to the blocking time caused by implementing the item. This term may in such a case be used as a proxy for duration measured in units of time. This issue has been addressed in this series here: WSJF - Should you divide by Lead Time or Size? which also identifies additional assumptions required for this to be true.
  4. WSJF itself is used consistently with its intended dimensions, which are value/time2
Proportionality must also be addressed. The scale used in estimating must be proportional (including 0 and not limiting maximum range) not just ordinal as would occur if the items with minimum and maximum value are set at say 1 and 20 respectively. The use of a weighting term to ensure the tangible and intangible business value terms are appropriately scaled relative to each other which is also required for proportionality.

The modified SAFe formula suggests a more general expression for WSJF using the weighting factors for a set of "business value types", v, and "exchange rates" that convert the values to a common "currency" of value:

WSJF = τΣ(vn Xn) / D

τ (tau) is time criticality, vn is the nth business value, Xn is the exchange rate for this business value type, D is duration, for which Size may be a proxy subject to the assumptions discussed above.

This blog has not addressed the issue of when quantitative or qualitative approaches should be used. As well as having formulae that are coherent, the work of estimating to provide numbers for the formulae must be worthwhile and comprehensible to the business doing such estimation. In many cases it is not - for example where the domain or context in inherently "non-plannable". The concept of cost of delay is still important, but we should for different techniques for ordering work. Further discussion of this must wait for the next article in the series.

Previous blogs:


Part 1: Understanding Cost of Delay and its Use in Kanban 
Part 2: 
Delay Cost and Urgency Profiles
Part 3: 
How to Calculate WSJF
Part 4: 
WSJF - Should you divide by Lead Time or Size?
Part 5: A "Qualitative" Formula for WSJF? (this article)

Part 6: Time is an Asset - Delay is a Cost

References

[1] David J. Anderson and Andy Carmichael, Essential Kanban Condensed. (United States: Lean Kanban University Press. 2016)
[2] Anderson, David. 2015. ESP: Scaling the benefits of Kanban. Slides 45-49. April 23. http://www.slideshare.net/agilemanager/enterprise-services-planning-scaling-the-benefits-of-kanban (January 5, 2017).
[3] Sharvari, Sawant. 2016. "SwiftKanban help - risk module.". http://help.swiftkanban.com/getting-started/projects/metrics/esp-analytics/risk-management.html(January 5, 2017).
[4] Magennis, Troy. 2016. Better Backlog Prioritization (from random to lifetime cost of delay). https://github.com/FocusedObjective/FocusedObjective.Resources/raw/master/Canvas%20and%20Forms/Better%20Backlog%20Prioritization.pdf
[5] Agile, Scaled. 2016. "WSJF – scaled agile framework.". http://www.scaledagileframework.com/ wsjf/ (January 5, 2017).

Post a Comment

Popular posts from this blog

Does your Definition of Done allow known defects?

Is it just me or do you also find it odd that some teams have clauses like this in their definition of done (DoD)?
... the Story will contain defects of level 3 severity or less only ... Of course they don't mean you have to put minor bugs in your code - that really would be mad - but it does mean you can sign the Story off as "Done"if the bugs you discover in it are only minor (like spelling mistakes, graphical misalignment, faults with easy workarounds, etc.). I saw DoDs like this some time ago and was seriously puzzled by the madness of it. I was reminded of it again at a meet-up discussion recently - it's clearly a practice that's not uncommon.

Let's look at the consequences of this policy. 

Potentially for every User Story that is signed off as "Done" there could be several additional Defect Stories (of low priority) that will be created. It's possible that finishing a Story (with no additional user requirements) will result in an increase in…

"Plan of Intent" and "Plan of Record"

Ron Lichty is well known in the Software Engineering community on the West Coast as a practitioner, as a seasoned project manager of many successful ventures and in a number of SIGs and conferences in which he is active. In spite of knowing Ron by correspondence over a long period of time it was only at JavaOne this year that we finally got together and I'm very glad we did.

Ron wrote to me after our meeting:

I told a number of people later at JavaOne, and even later that evening at the Software Engineering Management SIG, about xProcess. It really looks good. A question came up: It's a common technique in large organizations to keep a "Plan of Intent" and a "Plan of Record" - to have two project plans, one for the business partners and boss, one you actually execute to. Any support for that in xProcess?

Good question! Here's my reply...

There is support in xProcess for an arbitrary number of target levels through what we call (in the process definitions) P…

Understanding Cost of Delay and its Use in Kanban

Cost of Delay (CoD) is a vital concept to understand in product development. It should be a guide to the ordering of work items, even if - as is often the case - estimating it quantitatively may be difficult or even impossible. Analysing Cost of Delay (even if done qualitatively) is important because it focuses on the business value of work items and how that value changes over time. An understanding of Cost of Delay is essential if you want to maximise the flow of value to your customers.

Don Reinertsen in his book Flow [1] has shown that, if you want to deliver the maximum business value with a given size team, you give the highest priority, not to the most valuable work items in your "pool of ideas," not even to the most urgent items (those whose business value decays at the fastest rate), nor to your smallest items. Rather you should prioritise those items with the highest value of urgency (or CoD) divided by the time taken to implement them. Reinertsen called this appro…