14

Portfolio Backlog Management

In previous chapters, we have looked at the importance of an Enterprise Strategy, how we connect the portfolio to the Enterprise Strategy via Strategic Themes, the various tools and techniques to help define the portfolio, and then the critical stage of identifying our Value Streams. Having identified our Value Streams, we then explored how we fund Value Streams rather than projects moving away from traditional Project-Cost Accounting.

So, now we need to consider how we visualize the progress of our work, in this case, the Epics, using our Value Streams.

The Portfolio Kanban is particularly important in that it helps align the strategy and its execution by identifying, communicating, and governing the selection of the largest and most strategic initiatives (Epics) for a SAFe® Portfolio. The Portfolio Kanban is operated under the auspices of Lean Portfolio Management and uses the Strategic Portfolio Review and Portfolio Sync events to manage and monitor the flow of work.

In this chapter, we will cover the following:

• Portfolio Epics
• The Portfolio Kanban system and the various states that manage the flow of Epics from ideation to implementation and completion
• The Portfolio Sync events and related governance

But first, what do we mean by a Portfolio Epic?

Portfolio Epics

A Portfolio Epic is a significant solution initiative. There are two types of Portfolio Epics:

• Business Epics that directly deliver Business Value
• Enabler Epics that support the Architectural Runway and future business functionality

Caution

Epics are not merely a synonym for projects; they operate quite differently. Epics represent a significant opportunity and also are not a large collection of Features. There can be lots of great ideas that don’t qualify as Epics. They may be more appropriately planned as Features.

Portfolio Epics are typically cross-cutting, spanning multiple Value Streams and PIs.

Pro tip

Even though Epics can span multiple PIs, I always try and create Epics that span maybe three or four PIs at most. Try and break a larger Epic into smaller Epics; otherwise, it will distort the prioritization. The larger Epics will naturally fall to the bottom of the Portfolio Backlog because of the effort/duration when we use economic prioritization (Weighted Shortest Job First (WSJF)). Plus, with a “smaller” Epic, you get feedback earlier.

Each Epic will need an Epic Owner. Epic Owners are responsible for coordinating Portfolio Epics through the Portfolio Kanban system. They collaboratively define the Epic, its Minimum Viable Product (MVP), and its Lean Business Case, and when approved, facilitate its implementation.

Figure 14.1 illustrates the four primary responsibilities of an Epic Owner:

Figure 14.1 – The Epic Owners’ four areas of primary responsibility (© Scaled Agile Inc)

Pro tip

Because the Epic Owner needs to shepherd the Epic through the Portfolio Kanban system (which will require an understanding of Lean Portfolio Management and a significant degree of collaboration with various senior Stakeholders), we often see a senior Project Manager or portfolio Manager undertake this role, supported by enterprise business and system analysts.

In the next section, we will look at how we can define an Epic, its MVP, and the Lean Business Case.

The Portfolio Kanban

The Portfolio Kanban system is a method for visualizing and managing the flow of Portfolio Epics, from ideation through analysis, implementation, and completion, as illustrated in Figure 14.2:

Figure 14.2 – Portfolio Kanban (© Scaled Agile Inc)

There are several Kanban systems used throughout SAFe®, including the Team, ART, Solution, and Portfolio Kanban systems. These systems help match demand to capacity based on Work in Progress (WIP) limits; visualizing bottlenecks in each process state helps identify opportunities for relentless improvement.

It’s important to note that the Portfolio Kanban in Figure 14.2 is a prototypical Kanban; the design of the Kanban should evolve to reflect improvements to the default Kanban states based on relevant portfolio experience. These improvements may include adjusting WIP limits, splitting or combining Kanban states, or adding classes of service to optimize the flow and priority of Epics.

Pro tip

I find that the Kanban designed in Figure 14.2 is a good starting point and tends to “work out of the box” but then you should evolve your Kanban over time with your experience and context. This is only true of the Portfolio Kanban; the other Kanbans need to be designed based on your context. However, all Kanbans should evolve over time.

We will now briefly explore the states of the Portfolio Kanban.

The Funnel

We want a system where all ideas are welcomed; it could be anything from a simple email inbox to a page on a collaborative website (e.g., Confluence), but the key here is that we just want a simple expression of the idea – more often than not, a one-liner. We can then assess this one-liner to see whether it is aligned with our Strategic Themes and whether it meets the following criteria:

• Desirable
• Viable
• Feasible
• Sustainable

If it doesn’t fulfill these criteria, then we need to archive that particular idea. Let me give you a real-life example.

Story from the real world

Let’s refer back to my ferry company that we discussed in Chapter 13. This ferry company had already survived two existential events:

1. The loss of duty-free goods that could be sold onboard

2. The introduction of the Eurotunnel connecting England to France

However, early in the 2000s, low-cost airlines started to penetrate the travel market, whereby you could now fly from the UK to the south of France for less than €10, as opposed to getting on a ferry from Dover to Calais and then driving the 10 hours or so down to the south of France. Moreover, these low-cost airlines were very lean compared to the ferry company, which had significant fixed costs.

The CEO stated that in order to survive, we had to become a leaner organization, and while the executive had some ideas, she also recognized that they didn’t have all the answers. The CEO asked everyone to think of ideas that would generate cost savings and all that the CEO demanded was a simple statement to be sent to a collection email.

At the time, the cost of a barrel of oil was at an all-time high and we burned a lot of oil on our ferries. Therefore, one of the suggestions was to convert all our ferries into using nuclear power!

Now, that certainly met the Strategic Theme in terms of cost reduction (over time) but not the four measures of desirable, viable, feasible, and sustainable. That idea was quickly discounted. However, some ideas will meet the initial test and progress to the next stage of Reviewing.

Reviewing

This is where we convert the one-liner into a one-pager and create an Epic Hypothesis Statement (EHS), as shown in Figure 14.3:

Figure 14.3 – EHS (© Scaled Agile, Inc.)

This is the point at which we assign an Epic Owner, who won’t always be the person that created the idea but will be someone that can shepherd the Epic through the Portfolio Kanban and help create the necessary information to ultimately get approval from Lean Portfolio Management. As suggested earlier, often, a Project Manager who knows the business and can collaborate with key Stakeholders makes a very good candidate for Epic Owner.

The EHS is like an elevator pitch for the idea. An elevator pitch is a brief (think 30 seconds!) way of introducing the idea, getting across a key point or two, and making a connection with someone. It’s called an elevator pitch because it takes roughly the amount of time you’d spend riding in an elevator with someone. If you happen to bump into someone you want to tell about your idea in an elevator, what will you say to get your point across — all before that person exits the elevator?

Most people are fairly comfortable with completing the Epic Description and the Business Outcomes but then start to struggle with the Leading Indicators. We will discuss Leading Indicators in Chapter 15 but for now, Leading Indicators are the metrics that demonstrate that, as we develop the Epic, it will meet the Business Outcomes. Generally, we are very good at Lagging Indicators – as in, what value the Epic will generate when completed, but that might be months and years later. As we develop the Epic, what comfort can we take to generate confidence that we will meet these outcomes?

Story from the real world

An example we often use is Tesla. When launching the Model 3 in March 2016, Tesla wanted a $1,000 refundable deposit and expression of intent. Almost half a million put down $1,000, even though it was a 2-3 year wait. This was a clear leading indicator that there was a demand for a car that was not even built!

Again, after completing the EHS, if this Epic has merit, then it will be pulled to the next stage, proving the Epic Owner has the capacity and/or the Portfolio Kanban WIP isn’t also exceeded.

Analyzing

This is where we go from a one-pager to a slide-deck presentation, and the presentation must include the following:

1. The high-level Features of the Epic
2. A defined MVP
3. Solution alternatives
4. Refined cost estimates from the EHS
5. A Lean Business Case

Let’s have a look at these in turn.

The High-Level Features of the Epic

Break down the Epic into high-level Features based on the business objectives and user roles. Use the following guidelines to create Features:

• Each Feature should align with one or more business objectives.
• Each Feature should address the needs of one or more user roles.
• Ideally, each Feature should be small enough to be delivered in a single PI or less; however, at this stage, don’t worry if the Feature is bigger than a single PI because we will have time later to refine that Feature as part of the preparation for PI Planning.

A Defined Minimum Viable Product (MVP)

MVP is the most misunderstood term in Agile – it is not the crappiest version that we can release to the market as soon as possible, which is a common misconception, and, as a consequence, has created an allergic reaction to MVPs.

Our preference is the definition from Eric Rees and his book Lean Start-up:

“[the] version of a new product which allows a team to collect the maximum amount of validated learning about customers with the least effort”

In his book, Eric explains that MVPs range from extremely simple smoke tests (little more than an advertisement) to actual early prototypes, complete with problems and missing Features.

What is the minimum we can do to validate or invalidate our hypothesis– that is, our MVP?

Solution Alternatives

We also need to understand that at this early stage of the Epic, we may not have all the answers and there may be various solution alternatives; we don’t want to be forced into making point solutions too early; rather, we would prefer to preserve options and the ability to explore these options through Set-Based Design (SBD). [1]

SBD is an approach to product or system design that emphasizes exploring multiple possible design solutions simultaneously before making a final selection. The process involves creating sets of possible design alternatives, evaluating their strengths and weaknesses, and then selecting the best alternative based on a set of predefined criteria.

The goal of SBD is to reduce the risk of making a poor design decision by exploring a broad range of potential solutions before committing to a single design. By considering multiple design alternatives simultaneously, SBD encourages designers to think creatively and explore a wider range of possibilities.

SBD is often used in complex engineering projects, where design decisions have far-reaching consequences and a high degree of certainty is required. By using this approach, designers can reduce the likelihood of costly redesigns and minimize the risk of solution failure.

This is the opposite of “just picking one.” In SBD, teams identify and simultaneously vet possible options, committing to implementing a technical solution only after testing and validating assumptions. SBD is best suited to situations with a high degree of innovation or variability involved, or problems with immovable deadlines.

Refined Cost Estimates from the EHS

You will have created an initial cost estimate in Reviewing when defining for EHS. However, having now created the high-level Features and the solution alternatives, you will need to refine these cost estimates.

For example, you can estimate the costs associated with each Feature of the Epic using a combination of top-down and bottom-up approaches. Use data from past Epics, industry benchmarks, and expert opinions to refine the estimates.

You should also refine the cost estimates based on feedback from Stakeholders and any changes in the scope of the Epic.

A Lean Business Case

Finally, we need to complete a Lean Business Case; Lean because it only extends to two pages! Scaled Agile, Inc. has created a template that you can download from their website (https://scaledagileframework.com/epic/).

It is at this stage that we present our case to the Lean Portfolio Management function to make a go/no-go decision.

Our experience from the many organizations that we have supported is that this function normally exists, but it may go under a different title – for example, the Steering Committee, Investment Committee, or something similar. We just need to re-purpose that function to operate in a more Lean-Agile fashion, and this is where the education that we describe in Chapter 12 becomes important.

The Portfolio Backlog

If the Epic is not approved, it might cycle back through Reviewing and/or Analysis of the Portfolio Kanban or be archived. If it is approved, it is moved into the Portfolio Backlog, which is a lightweight holding area for all approved Epics. These Epics will be prioritized using WSJF.

These Epics will only be pulled into Implementing when there is the budget available, as determined by Participatory Budgeting (PB) (if used), and if there is capacity.

Implementing

This is where we start to build our MVPs, although we would suggest that maybe some MVP work could be done in Analyzing, particularly if it was simple smoke testing.

For Implementing, we follow the lean start-up cycle, a highly-iterative process of building, measuring, and learning (see Figure 14.4).

Figure 14.4 – Epics in the Lean Start-up Cycle (© Scaled Agile, Inc.)

At each iteration of the MVP, we ask ourselves “Is the hypothesis proven?” If not, then we pivot without mercy or guilt. If yes, we persevere until portfolio governance is no longer required. These MVPs and the related Features will be developed by the appropriate ART for that Value Stream.

Done

After evaluating an Epic’s hypothesis, it may or may not be considered to still be a portfolio concern. An Epic is considered Done when sufficient knowledge or value is achieved, or it is no longer a portfolio concern. Completing the fully envisioned scope from the Lean Business Case is not a criterion. Instead, the Epic is Done if the following are met:

• It is ejected from the Portfolio Kanban by LPM in any of the earlier states.
• The hypothesis is proven, and LPM has determined that additional portfolio governance is no longer required. This WILL vary from organization to organization. However, the Epic Owner may have some ongoing responsibilities for stewardship and follow-up.

The empowerment and decentralized decision-making of Lean budgets depend on the guardrails of your particular organization. For example, the Epic is now in production, creating ongoing value, and we are now only enhancing the Epic, so it can now be considered in Horizon 1, particularly if we are extracting rather than investing. That might cause us to determine it to no longer be a portfolio concern.

Lean Portfolio Management Events and Governance

We have touched on the need for Lean Portfolio Management to provide approval for the Epics before we start Implementing, but what are the other events that we need to establish to support the progress of the Epics through the Kanban system? We will explore that next.

There are three main LPM events:

• The Portfolio Sync
• The Strategic Portfolio Review
• PB

Let’s look at each of these in turn.

The Portfolio Sync

By its very definition, this is focused on a more operational level than the Strategic Portfolio Review. It is typically held monthly and may be replaced or extended on a given month by the Strategic Portfolio Review. Topics normally include the following:

• Reviewing Epic implementation: Review in-flight Epics and advance Epics through the Kanban system
• Reviewing the status of Value Stream KPIs: Collect portfolio metrics and Value Stream KPIs
• Addressing dependencies: Try and remove dependencies rather than manage dependencies
• Removing impediments: Address blocks and impediments

This meeting generally lasts for 1 to 2 hours but is dependent on the size of the portfolio.

Pro tip

Initially, consider holding this meeting every two weeks and moving to a monthly cadence as the LPM functions mature.

In addition, a suggested agenda to get you started is as follows:

1. Review the progress of actions from the last meeting.
2. Address blockers and impediments that require LPM assistance by assessing Epics from right to left on the Portfolio Kanban.
3. Review and decide on MVP results.
4. Discuss go/no-go decisions.
5. Review new Epics (Objectives and Key Results and Threshold) and Epics in progress (enforcing exit criteria).
6. Reprioritize the Portfolio Backlog, if required.
7. Summary of meet-after topics.

The Strategic Portfolio Review

The focus of this event is on achieving and advancing the Portfolio Vision. It is typically held quarterly, at least one month before the next PI Planning to enable Value Streams to prepare and respond to any changes. Topics normally include the following:

• Reviewing strategy: Review and update the Strategic Themes and maintain the Portfolio Vision
• Reviewing Implementation: Evaluate MVPs and make decisions
• Reviewing budgets: Review investment horizons and other Lean budget guardrails

Unlike the Portfolio Sync, this is a more significant event that happens every quarter and our experience is that this is typically a 1 or 2-day workshop. Again, to get you started, here is a suggested agenda:

1. Review the progress toward the Strategic Themes and discuss whether they need to be amended.
2. Review the Portfolio Vision via a SWOT and TOWS (see Chapter 12) analysis and revise the Portfolio Vision.
3. Identify the potential Epics.
4. Review the budgets and verify any adjustments.
5. Build the Portfolio Roadmap of themes, Initiatives, Epics, and Enablers.
6. Review the ART construct for the portfolio and confirm whether it requires adjustment to support the 2-3 year Portfolio Roadmap.
7. Review the portfolio spend performance in the last 6 months and verify adjustments to the funding Horizon targets.

Caution

With the suggested agendas for the Portfolio Sync and the Strategic Portfolio Review, please remember they are suggestions, and tailoring them to your context and portfolio will be required, but we wanted to give you some ideas to help you craft an agenda.

Participatory Budgeting (PB)

We have already described this in Chapter 13; however, this event is typically held twice a year; if budgets are adjusted less frequently, spending is fixed for too long, limiting agility. More frequent budget changes may seem to support increased agility but, in turn, may create too much uncertainty.

Summary

With this chapter, we learned that strategy and investment funding ensure the right work is happening at the right time. Continuous and early feedback on current initiatives, coupled with a Lean approach to funding, allows the portfolio to make the necessary adjustments to meet its business targets. Lean governance closes the loop by measuring portfolio performance and supporting dynamic adjustments to budgets to maximize value.

In the next chapter, we will look at how we measure progress empirically across our Portfolio.

Further reading

1. Set-Based Design: https://scaledagileframework.com/set-based-design/
2. Lean Portfolio Management: https://scaledagileframework.com/lean-portfolio-management/