On The Nature Of Portfolios - Portfolio Roadmapping - Epic Roadmaps

Author(s):

“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 Forecasting & Road Mapping

Previous blogs explored the topic of using Weighted Shortest Job First and the conclusions drawn were that WSJF alone is not enough to manage a Portfolio; other activities are necessary to allow a Portfolio to make informed decisions. Performing the Weighted Shortest Job First algorithm also requires supporting activities, the Time Criticality component of WSJF is difficult to assess without an understanding of timelines and for that a Roadmap is required.

The focus of the current set of blogs is Portfolio Level Roadmapping. The previous blogs have examined “Why do we need to roadmap?” and provided practical advice on the challenges of building a roadmap in a collaborative fashion.

This post covers Epic Roadmaps.

Epic Roadmaps

Epics often want a roadmap to forecast whether they are going to hit the key dates and deadlines that they are working towards. However, Epics don’t exist in isolation, there are often many active Epics within a Portfolio competing for space on the Agile Release Train backlogs; that needs to be factored into the Epic Road-mapping process.

The truth exists within the Agile Release Trains. That is where the inputs from all the in-play Epics are combined, along with any locally generated work. That is where the knowledge about sequencing exists. Therefore, an Epic can’t develop a roadmap in insolation, by necessity it will need to collaborate with the ARTs in order to build a roadmap.

Informs

Epics start with their key milestones and a “preferred sequence”. Key milestones represent targets that need to be hit. The preferred sequence is the order in which the Epic would like to try and tackle the problems that need to be solved in order to achieve the Epic’s Business Outcomes. It is preferable if the preferred sequence problems to solve or outcomes to achieve, rather than work to be done, as that helps contribute to the Lean-Startup mindset and empowers the ARTs and Teams to come up with solutions.

The Epic engages with the Agile Release Trains to get them to create candidate Features or Feature groups that can realise those outcomes. The engagement with the ARTs creates collaboration and empowerment where the Epic solicits input from the ARTs rather than an imposition where the Epic dictates what the ARTs should do.

It also helps if the Epic understands where there are constraints and where there is room for negotiation; this will aid the ARTs when constructing their own roadmaps. Which facets of the Iron Triangle or Scope, Time and Cost are available for negotiation? Since Epics just represent the “work”, not the “people”, their two main points of negotiation are either Scope or Time.

Scope: How, the solutions, to achieving the Business Outcomes are achieved.
Time: How moveable are the dates and deadlines?
Cost: is negotiated across Epics and is represented by how much effort this Epic can negotiate the ARTs into devoting to this Epic.

Any Epic that attempts to fix both Time and Scope has to hope that there are other Epics in-play that are less important so that the effort from those less important Epics can be diverted to the more important Epics. That is a lot harder for an individual Epic to control since it is outside the scope of the Epic; it becomes a cross-Epic negotiation. Clear prioritisation of the Epics at the Portfolio level will help with any cross-Epic negotiations.

ART Roadmaps

The Epic negotiates space reservations on the ART Roadmaps; the collaborative road-mapping techniques from the previous blog post could be utilised with the participants being the set of Epic Owners that need to negotiate amongst each other.

The conversations balancing the needs of an Epic against other Epics must always take place at the Train level because the “Nice-To-Haves” of a high priority Epic might not be as important as the “Must-Haves” of a lower priority Epic; that only becomes visible in the Train level roadmaps and backlogs.

The candidate Features or Feature Groups that the Epic is negotiating into the ARTs for roadmapping purposed do not need a large amount of detail. For roadmapping purposes a phrase and an estimate are enough to reserve space on the roadmap and to facilitate forecasting. The elaboration of detail can be deferred until the Program Backlog refinement activitied in the Program Increment before the Program Increment in which the Feature is expected to be planned.

Aggregate & Filter

ART roadmaps can be aggregated up and then filtered to show just the Features related to this Epic. The derived roadmap can show when and which teams are contributing to the Epic, the work they intend to do and how that lines up against the dates and deadlines. If the train level roadmaps change, and they should be updated every PI to reflect the latest insight gained from completing a PI, then the derived roadmap will change; it reflects the latest truth coming up from the Agile Release Trains.

Use the roadmap as a forecasting tool; it is providing insight into whether the dates and deadlines are achievable given the current scope and current capacity allocations. If the answers coming back from the roadmapping and forecasting are that dates aren’t achievable then it’s time to start negotiating.

The obvious thing to negotiate is Priority, but this is the wrong approach. If you do try to increase the priority of an Epic based upon it’s forecasts showing that it will miss it’s deadlines then, when this Epic gains priority and gains more capacity because capacity is fixed another Epic will lose out, when the new forecasts for that Epic indicate that it’s missing its deadlines then it’s priority will be raised and the first Epic will lose it’s priority and capacity, creating a circular argument that can never be resolved. A forecast that shows that an Epic won’t meet it’s deadlines doesn’t materially change the business cases of this or any of the other Epics and the prioritisation of the set of Epics is on the Business Case. If the Business Case hasn’t changed then the priorities won’t change.

Any negotiation has to be within the Epic itself.

Negotiate inwards: are there other less important things within the scope of the Epic that can be deprioritised and deferred in order to remain focused on only those things absolutely necessary to meet the dates.

Negotiate outwards: with the parties outside the Epic to see whether the outcomes and deadlines can be changed?

Don’t assume that more effort, money, or good-luck will come along in the future. Plan for the worst case scenario: What you’ve got now is all you’re going to get!

Embrace Variability, Preserve Options

Epic roadmaps will change. The changes might be arising internally, Lean-Startup experiments providing information that changes the preferred sequence. The changes might arise externally, as the priorities between Epics change the capacity Agile Release Trains can allocated to Epics will change and therefore how the preferred sequence is realised at the ART level will change.

What Next?

This completes, for the moment, the exploration of Portfolio Roadmapping. The next article will look at Estimating Effort Or Expense? before moving on to OKRs.