Back to top

On The Nature Of Portfolios - Portfolio Roadmapping

Author(s) 

On The Nature Of Portfolios

Portfolio Roadmaps

“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 Mappingt

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. The Weighted Shortest Job First algorithm also requires supporting activities, particularly the Time Criticality component of WSJF can’t be assessed 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 blog looked into Why do we need to roadmap and covered some of the challenges that Portfolio Level Roadmapping faces.

This post covers some practical facilitation techniques. Presented here in the context of the Portfolio; these techniques aren’t exclusive to the Portfolio and can be used by anyone that needs to create a roadmap.

Practicalities Of Portfolio Roadmapping

Outcome Base Road mapping

Rather than a roadmap specify what needs to happen, a sequence of solutions, the roadmap can contain Outcomes that are desired and the deadlines by which those outcomes are needed. By specifying the Roadmap as outcomes rather than work items it gives the teams the flexibility around how they achieve those outcomes and empowers them to come up with solutions rather than

This is Design Thinking’s separation of Problem and Solution at work. The Roadmap exists in Problem Space, the outcomes on the roadmap are problems to be solved, which empowers the Trains and Teams.

Elaborate?

Collaborative Road mapping

Road mapping is another activity that can benefit from the “all hands” approach that PI Planning utilises. The act of everyone creating the roadmap collaboratively generates alignment amongst the group and gets individuals with differing needs to see and understand other needs that are drawing upon the same fixed set of resources.

  • The process requires a long wide space, a wall of whiteboards or a long boardroom table is ideal. Divide the space up into segments that represent timeboxes within the time horizon over which the roadmap is being developed. For Portfolio road-mapping exercises this will be Program Increments over
  • Using the latest historical data from the Trains for their velocity each PI can be given a capacity; written on a Post-It at the top of the segment for that PI. I like to taper the velocity off over time, successive Program Increments are 80%, 60%, 40% of the current capacity. This represent uncertainty in the capacity going forwards but also the expectation that new work will be found that consumes the reserved capacity; if no work is found then later stages of the roadmap are pulled forwards. It’s trying to pro-actively manage expectations and get participants to understand and embrace the uncertainty and variability that is inherent in problem solving.
  • Mark out the capacity allocation available for Business work and Internal work1.
  • All of the Work being considered needs a name and an estimate, ideally the estimates have been done in advance by engineering representatives. The owner of the work item receives a Post-It representing that work item.
  • The vision is described, usually by the most senior person in the room. Key dates are highlighted and corresponding markers added to the roadmap.
  • The participants can now discuss their work items and place them on the roadmap. As items are placed onto the roadmap the loading for a PI can be calculated by summing together all the estimates. The loading should be below the available capacity.
  • If the work items are Epics then they will need to be sliced into pieces that fit within the relevant timebox. Try to remain outcomes based for the slices, what are you trying to achieve rather than work to be done. This leans towards the Lean-Startup mentality and helps with WSJF as described in an earlier blog post on WSJF using Experimental Effort
  • Is the sequencing right? Is the work necessary to achieve an outcome being done before any associated deadlines? There is likely to be some negotiations to move items around the roadmap to get the sequencing right.
  • The representatives of the engineering discipline, Enterprise, Solution or System architects can look at the upcoming work on the roadmap and ask themselves the question “Is there anything that needs to be done earlier to support future deliveries?” They can create Enabler features and add them to the roadmap.
  • The process repeats until either the work or available capacity is used up.
  • Check for bottlenecks particularly resource or skill constraints. Is there too much work-in-progress?
  • Are the guardrails being honoured? The two guardrails directly applicable to Portfolio Road Mapping here are Capacity Allocation and Investment Horizons. Continuous Business Engagement should be handled by the Business participating. The Epic Approvals isn’t applicable at this stage.

If the above sounds a little like the team breakout session of PI Planning but with Epics or Features instead of Stories and Program Increments instead of Sprints/Iterations, then you’re on the right track and you probably already know how to facilitate the event. Credit the MPS2 team at Ford.

Visualise and Limit WIP

SAFe Principle #6 – Visualise and limit WIP , reduce batch sizes, and manage queue lengths; roadmaps provide a way for visualizing and managing WIP.

Scenario Planning – Pathfinding

You don’t have to think of these roadmaps as a simple linear sequence; consider scenarios. The roadmap could be a decision tree. Experiments derived from the Lean-Startup mentality form a branching point on the tree and the results once know would send the Portfolio in one direction or the other. Whilst the results from the experiment aren’t known until the experiment has been run, how the organisation should react can often be considered in advance; these form the decision tree.

The decision tree approach allows rationalisation around worst-case scenarios, check that if these were to occur then are the dates, the deadlines, still achievable. Remember that the roadmap isn’t fixed, if the happy path occurs rather than the worst case then work just gets pulled forwards and the roadmap and forecasts can be adjusted to reflect the latest information.

Where is the Truth?

Roadmaps provide intent, an idea of what the higher level would like to happen in the future. That intent informs the lower levels, trains and teams. It can provide them with a vision and an idea of what needs to be created in their backlogs. The Train and Team use these as inputs to their planning. What happens when the plans and information coming back from the teams doesn’t match the information that was on the roadmap?

The basic assumption at work is that the lower level information coming up is always more accurate than the high level information going down because the information is coming up from the people that will have to do the work and they know their owns skills the best. It’s exactly what is meant in < a href=” https://www.scaledagileframework.com/unlock-the-intrinsic-motivation-of-knowledge-workers/”>SAFe Principle #8 – Unlock the intrinsic motivation of knowledge workers when Peter Drucker talks about managing knowledge workers, the workers must be heard and respected. That new information needs to be fed into the roadmap and the roadmap recalculated, capacities of trains may change, estimates on work items will change as more knowledge is gained, the estimates may go up, the estimates may go down. With the truth being fed back into the roadmap it is possible to reassess whether deadlines can be met. If the assessment is that they can’t be met then corrective action needs to be taken; deprioritize or defer work to ensure that those work items contributing to the deadlines receive the focus and get done. If the assessment is that regardless of corrective action a deadline can’t be met then the deadline needs to be renegotiated. The worst thing that can possibly happen is that the higher levels just assume that the lower levels will magically take care of things when the numbers are telling them otherwise; something needs to change at the upper levels.

Who Facilitates?

Facilitating these activities falls to the APMO, Agile Program Management Office2. Discussed briefly in the Lean Portfolio Management article on ScaledAgileFramework.com the APMO are the facilitators, the Scrum Master equivalents, at the Protfolio level. They facilitate the processes that the decision makers in the Portfolio use to run the Portfolio. They can also help gather information and crunch numbers to support the decision makers in the Portfolio in making their decisions.

What Next?


#1 Internal capacity is colloquially referred to as Architectural capacity although that’s a mistake because the type of work, eg. Architectural Enablers and the source of the work Internal (the Train) vs External (the Business) is separate dimensions. It’s the source that determines which capacity allocation it comes from and internally generated work may be more that just architectural work, it could be learning activities or even new functionality that the train wants to implement. Similarly externally sourced work coming from the Business could be requesting architectural improvements as much as new functionality; the work type is irrelevant, if they’ve requested it it’s coming from their budget. #2 Scaled Agile have been trying to remove the word “Program” from their material because people keep misunderstanding it. They initially used it in the very old-school sense of “a group of people doing a set of work” and in the SAFe world view that work would be a sequence of Features not a sequence of Projects. If you’re reading this in the future then Program might finally have disappeared, in favour of something else.