“Always show your working out!” was the mantra of my maths teacher in senior school. This series of blog posts “On the Nature of Lean Portfolios” is an exploration of Lean Portfolios. It is the thought processes running through my mind, exploring the possibilities so that I understand why things are happening rather than just doing those things blindly. It is not intended to be a fait-accompli presentation of the Solutions within Lean Portfolios but an exploration of the Problems to understand whether the Solutions make sense. There are no guarantees that these discussions are correct, but I am hopeful that the journey of exploration itself will prove educational as things are learnt on the way.
Portfolio Use of Weighted Shortest Job First
The standard advice within SAFe is that when it comes to prioritisation use Weighted Shortest Job First (WSJF). It is a useful simplification to stop Cost-Of-Delay discussions getting unnecessarily complex, but there is more depth to the mechanic than people would assume from reading the SAFe webpage; depth that I’ve previously explored in a blog on The Subtleties of Weighted Shortest Job First.
Weighted Shortest Job First works at the Release Train level because the timeboxes, the Program Increments, exist. The challenge is that at the Portfolio level, where Epics can last for long periods of time, then I suspect that the “Shortest Job First” part of “Weighted Shortest Job First” is going to cause some problems. By its very nature going it’s to make it difficult to balance Short Term wins against Long Term investment, with the long term investment losing. Part of the reason for writing this blog series On The Nature Of Portfolios was to explore this very issue.
What follows over the next few postings are a series of “experiments” to explore the topic and look at the issues that arise. We’ll look at:
- WSJF using Total Epic Effort
- WSJF using Predicted Duration
- WSJF using Experimental Effort
- WSJF; what would Don do?
- WSJF considering Risk factors
WSJF, what would Don do?
WSJF as outlined within SAFe is a set of approximations and simplifications to allow the calculations to be done quickly and repeatedly. The results are good enough for prioritising features within a Program Increment but as we have seen in the earlier experiments; they start to suffer at the Portfolio level where there is a need to balance Short Term wins against Long Term investment.
For the Portfolio where the volume of work items flowing through is significantly less than a train backlog we could adopt a more rigorous approach to calculating WSJF.
Don Reinertsen and Joe Valone proposed a more accurate version of Cost-Of-Delay for Portfolio use at the 2019 SAFe Summit. Don’s accountancy spreadsheets hide some fairly simple maths which I’ll try to illustrate graphically.
Classic cost-of-delay : Inputs
- It starts with a predicted sales curve, typically this rises to a peak then tails off in a sort of bell shape.
- The sales curve gets multiplied with the price at which you can sell the item and this typically declines over time as market forces make the item less valuable over time.
- Production costs are then subtracted to leave the profit, production costs decrease over time as manufacturing improves its efficiency.
With the scenario set up we can now start investigating what happens when the availability of the product for sale is delayed. If the product is delayed then the Sales Profile will shift to the right, as will the Production Cost but the Sales Price remains where it is; the assumption being that the sales price is decaying from this moment in time, right now. As seen is the “Profit If Product Released Later” graph in the product is delayed then the profits are less because the price at which it can be sold is less because it has been decaying over time.
Classic cost-of-delay : Scenario Outputs
I would expect that the sales and price figures/graphs are influenced by Market Rythmns; Festive Decorations are not worth much once the December Holiday season is over; the Sale Price wouldn’t be lovely straight line but would have a catastrophic decline once the window of opportunity has passed. However, whilst such finesse might be useful in certain scenarios it’s not going to change the overall story; delay often results in less profits.
The sales and finance departments within an organisation should have historic figures to be able to make sensible predictions about how things might play out and it would be the Epic Owner’s job to develop these scenarios as part of building the Business Case for the Epic.
Observation: More accuracy doesn’t help
Don’s presentation shows that we can do better for Cost-Of-Delay, but it still doesn’t solve that fundamental challenge of how to balance Short Term wins against Long Term investments. A more accurate Cost-Of-Delay is just the numerator of the WSJF calculation; the divisor part of the calculation hasn’t changed and as we’ve seen in earlier experiments it’s the job size that is suppressing the Long Term investments.
Observation: Other interesting snippets from Don’s presentation
There are a couple of other things that Don mentioned that piqued my interest.
- “Peoples intuition is poor.” Kind of obvious but nice to have it stated!
- “Within 10% is close enough for financials.” I’ll be using that as a retort next time someone is questioning why some estimate didn’t meet an unachievable level of accuracy.
In the next posting we’ll look at whether there is a way of supplementing the standard WSJF to include Risk Factors to see if Risk can be used to suppress the tendency of the small items to dominate.
More Great Topics for Agile Teams
How many Features do you take to PO Planning? PI Planning Tips
On the Nature of Portfolios; WSJF Estimating Portfolio & WSJF
Program Level WSJF & Feature Slicing Program WSJF & Feature Slicing
All about Managing Dispersed Planning; WSJF Estimating Dispersed Planning Series
States of Epics The EPIC lifecycle