### 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?

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).

### 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?