Contact

On The Nature Of Portfolios - Portfolio WSJF - Part 6

On The Nature Of Portfolios

“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 is 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, Within the Investment Horizons

A few months ago I was chatting to colleague, and SAFe Fellow, Ian Spence and he’d had an idea that might solve the challenge of Portfolio level WSJF, how to balance long term investments against the quick wins. A challenge that I’ve discussed extensively in earlier blogs.

The idea of “keeping WSJF simple by exploiting the Investment Horizons” was a core part of his 2022 SAFe SUMMIT presentation towards a Leaner Portfolio. As he was yet to write the idea up, and had referenced this blog series in his presentation, we decided that this would be a good place to publish and further explore the idea.

So, the author will be switching to “we” in this co-authored blog.

What are the Investment Horizons and How are They Used?

The idea references the McKinsey Horizons Model which is incorporated into SAFe as one of the four Portfolio Guardrails. The short explanation is that: a Portfolio should deliberately reserve some time for:

  • Investing and exploiting the currently commercially available solutions (Horizon 1) to defend and extend your existing business. Investments within this horizon will produce a positive return on investment within a year from their approval.
  • Emerging new and next generation solutions (Horizon 2) to grow your business into new emerging markets and renew your organization. Investments in this horizon will produce a positive return within 1 to 2 years (1 year < time to return < 3 if you want to be pernickety) and will typically require substantial organizational change to take the emerging solutions to market.
  • Evaluating new ideas (Horizon 3) that will seed options for future growth. Investments within this Horizon will need see a return on investment for 3 years or more.

Capacity allocations will need to be made to ensure that there is investment in future growth and new transformative ideas otherwise short-term investment in the currently popular solutions will steal all the time and effort, because they are the current cash earners, and in doing so starve the Portfolio of the new solutions needed to replace the current ones when their time ends.

As an addition to the orignal 3 Horizons identified by McKinsey, Geoffery Moore added a 4th Horizon, Horizon 0. This represents the Solutions that have run their course and should now be decommissioned. Many organisations struggle with turning things off, nobody wants to use the budget for “The Replacement Solution” to turn of the “Old Solution”, so the “Old Solution” never gets turned off. Many organisations are awash with old “Zombie” solutions that are running in the background and slowly consuming the operational budget of the organisation. Geoffery Moore asserts that the authority required to get people to spend money on turning stuff off is so senior that sometimes it needs to come from the CEO themselves, hence instigating Horizon 0 to make it visible, and to allow formal allocation of budget to that Horizon in order to get old systems properly turned off.

The SAFe idea of mapping the current and proposed solutions to the investment horizons is a useful tool for understanding the current state of your portfolio but it only provides you with a snap-shot in-time (and is also more complicated than it first appears – the subject for a possible future blog).

Note: care must be taken that when using the investment horizons they are treated in the way that they were originally intended – as investment horizons and not some kind of solution lifecycle. It is quite possible to bring a new product to market and achieve a positive return within a year. This would make the investment in this new product a horizon one investment. It is also implies that there will be minimal internal disruption when taking the new product to market (disrupting the competition is much more fun than disrupting yourself). If the new product requires new or significant changes to the operational value streams, although the development may take less than a year, to achieve a positive return on the investment is likely to take more than a year making it a Horizon 2 or 3 investment.

It is much more powerful to relate the investment horizons to your significant portfolio investments, which in SAFe will typically take the form of Portfolio Epics.

Portfolio Epics and the Investment Horizons

As part of the Epic’s Lean Business Case you must forecast the return that you expect to achieve for the investment. This is what the Business Outcomes and Leading Indicators are for. To understand how the Epics relate to the Investment Horizons it is first necessary to consider how the value of a solution itself changes over time

The above graph shows the total profits for a solution over time; total profits being all the income the product has generated minus the expenditure to develop, maintain, support, market and sell the solution. The lifecycle begins at the point when an idea for a product appears and is broken down into 4 phases.

  • Initial investment: Exploring ideas is all expense; there is no income initially as there is no Solution to sell, just an idea that might one day become a product.
  • Into profitability: The idea has been developed sufficiently that there is now a Solution available and the income coming in is greater than the expenditure. As income from the Solution starts to build it should overtake the expenditure and move the Solution into profitability..
  • Decline: The Solution has run it’s course, income is tailing off and expenditure is greater than income so the total profits are being eaten away..
  • Total loss: Continued expenditure on a Solution that has no income will eventual consume any profits that had been made and eventually the expenditure will erode the profits until it becomes a total loss.

The horizontal (time) axis on the above diagram deliberately has no scale marking as it isn’t linear and the range will vary.

Solutions might traverse the timeline in a few months, e.g. Solutions for Retail Products with a limited shelf life, or Solutions might traverse the timeline over years, e.g. Solutions for Industrial Equipment where the products are expected to last decades.

The axis is non-linear, the illustration has been drawn for legibility. Solutions may pass through the phases at different rates. Some solutions might need little to no “Initial Investment” and progress through “Into Profitability” very rapidly, some might spend a lot more time in “Initial Investment”. For some solutions the “Into Profitability” might last only a few months, for some Solutions it might last years.

Solutions might not make it through all phases, indeed they shouldn’t. A business needs to spot Solutions going into decline and stop further expenditure on them in order to maximise the profits; very few Solutions should end up being a total loss. The means to avoid this will be explained shortly.

Therefore, the Horizons roughly map as:

  • Horizon 3: solutions that are 2-3 years from a return-on-investment, they are likely to be evaluating potential new solutions, therefore in the early, exploratory, part of the solution timeline.
  • Horizon 2: solutions that are a year away from a return-on-investment are likely to be productising a viable solution identified in Horizon 3 so that it becomes a new line of business; this is getting the Solution into profitability, the climb out of initial investment to get positive again.
  • Horizon 1: solutions that are delivering an immediate return-on-investment are the forward face of the profitable hump
  • Horizon 0: solutions that should be decommissioned, occupy the right-hand end of the timeline once total profits are starting to decline.

Epics are change requests to change a Solution to move it through it’s lifecycle. What an Epic should be focusing on to generate value will vary dependent upon the Horizon of the Solution that the Epic is manipulating.

  • Horizon 3: Epics relating to a Solution in Horizon 3 should be seeking to minimise the losses in the initial investment phase by discarding bad ideas as quickly as possible. Represented on the above diagram as the shaded portion on the far left of the timeline; the shaded area wants to be as small as possible.
    These would be the experiments that prove that the Solution is viable from a business perspective; that there are customers who are willing to buy the Solution. These experiments are represented in the Epic as experimental Leading Indicators.
    If the numbers aren’t good, cut your losses early before the expense builds up, pursue other ideas.
  • Horizon 2: Epics relating to a Solution in Horizon 2 should be seeking to get the Solution from loss making into profit as rapidly as possible.
    These early targets to reach profitability would be represented in the Epic as Business Outcomes
    If the numbers arising from the Business Outcomes aren’t good, stop.
  • Horizon 1: Epics on a Solution in Horizon 1 should be seeking to either steepen the curve or to continue to lift the curve.
    Steepening the curve is functionality that will generate profits more quickly.
    Lifting the curve is functionality that generates additional sales, or ongoing renewals. The targets to increase or maintain profitability would be represented in the Epic as Business Outcomes
    If the numbers arising from the Business Outcomes aren’t good, it might be time to abandon this change in favour of another that might get better results, or even potentially abandoning the Solution if it’s time has passed.
  • Horizon 0: Epics on a Solution in Horizon 0 should be seeking to preserve the accumulated profits by removing any expenditure now that incoming is reducing.
    The goal would be to complete the closing work as quickly and efficiently as possible to preserve the profits.

Epics aren’t constrained to a Horizon. Some Epics will naturally fit within a Horizon, particularly on long-lived Solutions. Some Epics will make changes that move a Solution across multiple Horizons; the focus of the changes the Epic is making will need to change as the Solution moves across the Horizons.

What should we use as the Duration parameter in WSJF?

From the previous blogs we’ve seen that there are a number of different ways in which the Duration parameter of the WSJF could be formed.

Observation: Separate Requested Effort, Planned Effort and Priority

Requested Effort is the amount of Effort that the Epic is requesting from the Development Value Streams in this timebox. Planned Effort is the amount of Effort that the Development Value Streams have given the Epic once they’ve been through their PI Planning Events. Priority is the relative priority to the other Epics within the Portfolio, which WSJF can provide.

The relationship is that if the Requested Effort and the Planned Effort don’t match and the Priority is high then this might be a trigger that there is a problem. Either the Development Value Streams haven’t honoured the priority and are doing something else, or the Epic is requesting more Effort than the Development Value Streams have available. However to obtain a Prioritisation it can’t be done on just the Requested Effort, that leads to the “As Below, so Above” and “Don’t Lose Focus” issues described in WSJF using Experimental Effort.

From the above observation the use of Experimental Effort, the effort within the timebox would be wrong since we want a priority for the Epic as a whole. Therefore Total Effort or Predicted Duration would be better options, of which Predicted Duration is probably the best as it can account for Development Value Streams swarming to complete Epics and extended Durations if only a small amount of effort can be allocated per-timebox.

The idea is to use the Investment Horizons to keep Portfolio WSJF simple by running the WSJF within the Horizons. This means that you are comparing like with like; Horizon 3 (blue sky ideas) with long lead times are being compared against other long lead time items. This simple separation negates the challenges identified in earlier discussions with using Total Effort or Predicted Duration.

If Total Effort is being used then, drawing upon previous discussions that explored the relationship between Cost and Effort, it would be possible to use Estimated Cost as a substitute for the duration parameter, assuming there are no other distortions that would mean that Duration ≠ Effort.

WSJF, Within Horizons

With all of the setup covered it should be possible to run the set of test data through this variant of algorithm.

The test set has been updated to include which Horizon each of the Epics exists in.

Horizon 3
Epic BV TC RR|OE CoD Effort WSJF
Product S 13 1 1 15 1 15
Horizon 2
Epic BV TC RR|OE CoD Effort WSJF
Product L 8
1 1 10 5 2
Horizon 1
Epic BV TC RR|OE CoD Effort WSJF
Regulatory (Swarm)
21 1 1 23 2 11.5
Enabler 1 1 5 7 5
~1.3

For the purposes of the following discussions we’ll say that the portfolio has a Total Effort of 10 and that the balance of effort between the horizons is H3 10%, H2 20%, H1 70%.

Product S is in Horizon 3 on its own. It can’t suck up all the effort with the promise of high rewards but “allegedly” small effort because the effort is constrained by the capacity available for Horizon 3. Its effort fits within the available capacity. Product L is in Horizon 2 on its own. The long lead time isn’t a problem for prioritisation because it’s not competing against anything else. Since there is a capacity allocation on the Horizon of 20%, which results in an available effort per Program Increment of 2, the Epic will take at 2.5 Program Increments to complete. Regulatory and Enabler are both competing for space in Horizon 1; however since that horizon gets most of the available capacity they both be fit. The regulatory piece has the higher priority.

Arguably the test set is too small to demonstrate this variant of the WSJF since there aren’t enough entries to see the prioritisation occurring within each of the horizons. It could be extended to include more within each horizon to show WSJF being run over each sub-set, but once separated into the horizons it just becomes a demonstration of running WSJF which isn’t that exciting. What happens to the prioritised Horizons once the prioritisation has been completed is more interesting.

Once each horizon has been prioritized the cut-off lines can be drawn to show where the available capacity ends. The Epics above the cut-off are the priorities for the next PI. This provides a priority within that horizon, but doesn’t give an absolute priority for the entire set. Is an Epic in Horizon 1 a higher priority than an Epic in Horizon 3? The lists need to be merged.

There is no algorithmic way to perform the merge without looping back into some of the convoluted discussions about WSJF that we’ve already been through; the situation has to be resolved through discussion, but there are options for resolving the merge:

  1. Seed the final list with the Horizon 1 epics (typically the largest capacity)
  2. Starting from the top insert (in order) the Horizon 2 epics at the appropriate spot
  3. Repeat for Horizon 3

Or

  1. For each Horizon 2 and Horizon 3 Epic, identify a slice of the Epic that’s less than a year in duration
  2. Add the slice into the Horizon 1 List
  3. Run WSJF across the Horizon 1 list that has been extended to contain the Horizon 2 and Horizon 3 slices

The former is probably easier, the latter becomes a variant of WSJF with Experimental Effort.

The key thing is we’ve sized the list and are just looking to rank the Epics in play, the ones above the cut-off, therefore a simple ranking is good enough; the Release Trains pulling Features and prioritising them in their backlog will take care of the rest…

Whilst not having am absolute priority could make Feature prioritisation harder, in reality it probably won’t. Each feature has to be discussed on it’s own merits because a “nice to have” Feature from the highest priority Epic might not be as important as the “Must Have” feature from a lower priority Epic. The interleaving always has to take place in the Feature backlogs at the Release Train level. The set of Epic priorities are useful inputs to the Feature prioritisation discussions but they are just one influence of many; Features from two Epics that have not been prioritised alongside each other, because they are from different horizons, can still be prioritised, because it’s done on an individual Feature’s merits; the conversations to do this might take longer because they don’t share a common reference point which the absolute priority provide, but it can still be done.

Consider Risks?

Probably not; trying to factor Risks into the algorithm as described in WSJF considering Risk Factors might have been a mistake. It was a useful detour as part of this series of articles exploring WSJF, because it enabled us to discuss risks, but not something that should be incorporated into WSJF.

It’s the job of the approvals process to consider the risks. If the risks are calculated into the WSJF then you don’t need approvals you just follow the algorithm1. However the algorithm isn’t capable of balancing the risk across the portfolio, it doesn’t account for the portfolio’s appetite for risk.

Observation: Appetite For Risk is separate from Priorities

WSJF is prioritisation for the set under construction, Approvals is about taking the set and considering “which one do we want to take the risk on and develop”.

Horizon 3 Epics in particular are risky, they’re pure experimentation and not all will succeed. The effort involved will not produce a return on investment, the exploration is pure expense. How much surplus profits does the portfolio have to fund that exploration? How much risk is it willing to take? No Prioritisation mechanism will help with these decisions, these are the decisions that the Lean Portfolio Management need to make. They must take some risks, to take no risks would be to always remain in Horizon 1 and there is always the possibility that the current Horizon 1 solutions will end, no operational value stream lasts forever2.

Horizon 2 Epics might fail to become productive lines of business. This happens all the time, products are there one minute and then gone; and it happens with physical products as much as does with IT products. The product, the Solution, hasn’t proved to be profitable so the organisation stops funding it, Google Betas that are discontinued, grocery lines that are in the supermarkets one month then gone. How much of an appetite does the Portfolio have for taking the risk that this Solution might not be profitable? Google’s advertising revenue from the search engine can fund an awful lot of risk, not all organisations are lucky enough to have a goose that lays golden eggs3.

The capacity allocation between the Horizons is there to ensure that some risk is taken for the sake of the future organisation.

WSJF, Conclusions

“All models are wrong, but some are useful”
George E. P. Box

WSJF, Within Horizons solves some of the challenges of balancing the Short Term wins against Long Term investment by using the Horizons to separate them. It works; Ian has been using this technique within the Portfolios of a large multi-billion dollar international organisation. It works extremely well for Horizon 1 and Horizon 2. It’s fairly good for Horizon 3 but there is always the challenge that there is no upper limit on duration for the return-on-investment in Horizon 3, any return that is too far into the future is always going to struggle to be prioritised.

It avoids premature slicing of Epics and the race to the bottom that can result in the Portfolio prioritising big Features rather than true Business Change because small slices are needed to “game” the algorithm.

The Capacity Allocation maintains the balance across the Horizons and the process honours that by utilising it rather than trying to cheat the inputs to honour the capacity allocation after the process has been run, which is what tends to happen with simple WSJF.

But, it only works with a true Product Mentality where Epics are ideas that could be pursued rather than the simplistic “work to be done”. Without the freedom to pick and choose ideas the portfolio is always going to be constrained and inflexible.

The challenge is most organisations have a surplus of Project Managers who care about work being done, and a lack of Product Managers that care about the Product they own and making it successful. Hence most portfolios lapse into a “work to be done” mentality rather than “success”.

Next Steps

If you’re reading this chronologically as the articles are published, then the next step is to return to Epics and look at Enabler Epics, or perhaps the role of Epic Owner.

If you’re reading this sequentially through the topics, the next step is to explore the feedback cycle of Epics and put the case for and against splitting large Epics.






#1 If you don’t need approvals, you don’t need the decision makers, the Executives that make up the Lean Portfolio Management. Just get rid of them… viva-la-revolution! Let us know how it all turns out, we’ll be watching from afar.
#2 Except for the tax office… we once did a Value Stream analysis workshop at a tax office, we traced the Operational Value Stream, “Taxing The Population”, back over 400years, it went back further still but we had better things to do… I did ask if they thought the Operation Value Stream was going stop anytime soon, the answer was a resounding no, people are still going to be paying taxes in the future.
#3 The Goose That Laid The Golden Eggs: one of Aesop’s Fables.

Subject: 

Contact Us