Ian Spence

Scagilize Network Partner (Trainer & Consultant), Advisor & SAFe Fellow


Lean Portfolio Management (LPM) is intended for the management of investment portfolios – it is set up to help balance the investments across a set of value streams and / or solutions. It is not intended to be an administrative function to handle a set of projects or manage the flow of work for a single solution. By definition, you do not have a portfolio if you are only responsible for one value stream, one solution or, as in many cases, one Agile Release Train.


Experience though tells us that LPM techniques can be useful in these situations, particularly if you have a large amount of discretionary spend or receive your funding from a variety of different sources.


In this latest short blog series, we will look at several ways that your Agile Release Trains (ARTs) can benefit from adopting LPM Techniques, starting with the idea of using Local Epics.

Local Epics and Epics of Convenience

In SAFe the Portfolio Backlog is made up of sets of Portfolio Epics that cut across multiple Planning Intervals (PIs) and / or multiple value streams and ARTs.


Each Portfolio Epic represents a large, longer-term investment and requires 1) a lean business case, 2) the production of a Minimal Viable Product (MVP) to prove the business hypothesis and 3) portfolio-level supervision.


To deliver a Portfolio Epic one or more trains will need to implement Features typically across more than one PI. Portfolio Epics are such significant investments that they need portfolio approval before they can be addressed by the ARTs.


The concept of Epics is also useful at the train level – previously these have been referred to as Program Epics and Solution Epics but are now referred to as Local Epics. Before Safe Version 6 I always referred to these local, non-Portfolio Epics as “Epics of Convenience” to distinguish them to more formal Portfolio Epics covered in detail in the SAFe training. I did this because 1) they do not obey the same rules as a Portfolio Epic, 2) they are optional, 3) they behave in the same whether they apply to and ART or a Solution Train, and 4) you only use them when they are convenient and make the work of the ART easier to understand.


Note: There are times when a Portfolio Epic will align nicely with one of the Portfolio's ARTs and only require effort from that one ART to be completed. As the work is localized to a single ART, some people refer to these Portfolio Epics as Local Epics. To be clear, our Local Epics are always non-portfolio Epics and are not created as part of managing a Portfolio, they are a train level concern created whenever it is convenient for the train’s Product Management Team to do so.

This provides a simple place to start as, to be honest, it doesn’t really matter what the things you place onto the Kanban are – they could be Projects or more SAFe-like Epics – or how they are being conducted – they could be traditional waterfall projects or more agile initiatives. The simple act of visualizing the work and its state is enough to get the conversation started.

 

When designing your initial Kanban, make sure that it is something that everyone can relate to and that will enable them to intuitively place their work into the right columns.


Some organizations have a well-defined existing way-of-working that they can use to seed their initial Kanban.  Others don’t appear to have any process at all and can start from a generic Kanban board layout, such as SAFe’s Example Portfolio Kanban. For example, my personal favourite ‘starter for ten’ board is shown below.

Creating and Using Local Epics

The Local Epics are typically created to 1) help manage the ART’s backlog and discretionary spend or 2) to represent the ART’s contribution to an external, separately approved initiative.


In the first case, the Local Epic is acting as a placeholder for a set of Features that share a common goal. They could represent, amongst other things:

  • Something you’d like added to the solution that is clearly too big to be treated as a single Feature.
  • A business objective that you’d like to achieve that would require the delivery of a set of Features.
  • A process improvement you’d like to make that couldn’t be expressed as one or two individual Features.
  • A local initiative to extend a specific area of the system's functionality or architecture.
     

These Local Epics are Epic in that they will take more than a single PI to achieve their objective.

In the second case, they make it clear what the ART has agreed to do to support a wider business initiative. For example:

  • If an ART is part of a SAFe portfolio and expected to contribute to a Portfolio Epic, then a Local Epic is a convenient way to represent, estimate and agree what the train will deliver without having to identify all the Features up front. If the Portfolio Epic is itself being delivered incrementally, there may be several Local Epics levied upon the ART.
  • If an ART is working within a more traditional project and program structure, it may be expected to contribute to many of the business’s projects and programs. Creating Local Epics to represent the major commitments to and / or expectations of these external endeavours is a convenient way to track and manage the train’s deliveries, dependencies, and commitments. Clearly this would be overkill if just one or two Features are required, but in those situations where the ART is making a major contribution to an external project or program then this additional layer of abstraction makes everybody’s life much simpler.

The key thing to remember is that these are not Portfolio Epics – they are just created when it is convenient for the ART. Because of this, there is:

  • No need for Portfolio supervision or approval – if this is needed, it would be a Portfolio Epic
  • No need for them to appear on the Portfolio Kanban – if this is needed, it would be a Portfolio Epic
  • No explicit need for a Lean Business Case – these are purely a local concern. We’ll discuss when you might want to create a business case for a Local Epic in the next section, but it is not mandatory as it is for Portfolio Epics.
  • No need for you to be doing or talking about Portfolio Management

Working with Local Epics – Some Hints and Tips

1. Use the SAFe Epic Template


When creating a Local Epic, it is always a good idea to follow the standard SAFe Epic Template and make sure that you clearly articulate the expected business outcomes as a set of measurable benefits. I find the best way to do this for a Local Epic is as an OKR. If the Local Epic has more than one objective, then I would split it into multiple Local Epics, one for each objective.

Leading Indicators are less likely to be applicable for Local Epics as they tend to be smaller and more focused than Portfolio Epics, and consequently generate business benefits much earlier.



2. Don’t produce unnecessary Lean Business Cases


When dealing with Local Epics, you don’t always need to produce a Lean Business Case.


  • Example 1: The Local Epic is part of a larger Portfolio Epic or external initiative.
    There is no need to do a Lean Business Case in this case, as one has already been created and approved for the broader initiative. 
    The Local Epic will need to be estimated to ensure that there is sufficient capacity available to address it, but beyond clearly establishing the business outcomes, the size estimate and any delivery constraints nothing else is really needed.


  • Example 2: The Local Epic is just there to represent a set of Features that the train is funding itself. 
    It is there to help manage the backlog and flesh out the roadmap.
    In this case, we can piggyback off the solution’s business case and locally prioritize and scope manage the Epic and its Features. Often it is enough to agree the outcome, establish a relative estimate and factor the Epic into our roadmap.



There will be situations where creating a lightweight business case for a Local Epic will benefit the ART, particularly when attempting to justify budgets or raise funds, but generally the support of the train’s Product Management Team, Architects and Business Owners is enough.



3. You don’t always need a Minimal Viable Product


There are many cases where Local Epics won’t need an MVP.


  • Example 1: The Local Epic is to do the MVP for a Portfolio Epic.
    When contributing to a Portfolio Epic the first Local Epic levied on the train is often to produce the Portfolio Epic’s MVP. It wouldn’t make a lot of sense to do an MVP for the MVP.


  • Example 2: The Local Epic is there to support a Portfolio Epic that has already successfully concluded its MVP.


  • Example 3 – The Local Epic is a placeholder for a low risk set of independent Features. 
    It will incrementally extend the system’s capability in one or two of its functional areas (for example improving the user interface or extending the system's functionality by adding more credit card types or APIs etc.). In this case whichever Feature is done first will directly contribute to the business outcome and provide some measurable benefit, so it makes little or no sense to undertake a formal MVP.


But be careful if the Local Epic is risky, it is not clear how the business benefits will be realized, or the Local Epic will require significant architectural change; then it is always beneficial to adopt the full Lean Start Up Cycle.

Conclusion

The ability to use Local Epics is a powerful tool to have in your Product Management Toolkit.

 

They are not part of Essential SAFe and are therefore not something that every ART will need, but they are a tool that can help you in many ways including:


  • Road mapping and communicating your intent – Local Epics provide a larger, business outcome focused element to include on your roadmaps that allows you to communicate your intent without discussing specific Features. They are particularly useful when trying to raise the money to fund your train.
  • Capacity Management and Forecasting – You can allocate capacity for any in-play Local Epics and use your Feature Velocity to help forecast their completion.
  • Managing your contribution to a Portfolio Epic – Creating a Local Epic to represent your contribution to a Portfolio Epic can help with your ART’s forecasting, road mapping, prioritization, dependency management, and reporting. They can also help prevent the premature injection of ill-defined Features into your ART Backlog.
  • Integrating your ART into your organization’s existing project management and portfolio management processes. You can create Local Epics to represent your contribution to any larger initiatives you are involved in – this works as well for any cross-cutting initiatives, traditional projects, or traditional programs you support as it does for Portfolio Epics. It will also help you roll your costs up if you need to cross-charge your time to external cost codes.


The key thing is not to think that because you are talking about Epics that you are a Portfolio or undertaking Lean Portfolio Management. You don’t need to create any more roles, teams, or events to benefit from the use of Local Epics.



Attributions:

  • SAFe and Scaled Agile Framework are registered trademarks of Scaled Agile, Inc.
Share by: