Epics should be described using an Epic Value Statement template as described below and also available as a “template” card in the “Template guidance lane” - in order to create new epics you can copy this card and just fill in the value statement using the template skeleton.

For

<customers>

who

<do something>

the

<solution>

is a

<something – the “how”>

that

<provides this value>

Unlike

<competitor, current solution, or non-existing solution>

our solution

<does something better – the “why”>

Scope

Success criteria:

• <criteria 1>

• <criteria 2>

In scope:

• <item 1>

• <item 2>

Out of scope:

• <item 1>

• <item 2>

NFRs: *

• <requirement 1>

• <requirement 2>

* Non Functional Requirement

Including Strategic Themes on the Portfolio Kanban Board

It is helpful then to have the current strategic themes visible on the Portfolio Kanban Board for alignment purposes so therefore there is a “Strategic Theme” card type on the Portfolio Kanban Board template. The lane location for strategic themes is helpful as well. You will pass over it when pulling cards from Funnel into Review. So it is a good opportunity to make sure what you're pulling is aligned to some current strategic theme.

It is also possible at this point to connect a theme to Epics that are aligned with it. Please note you cannot connect an Epic to multiple themes.

TIP: use a "Multi-theme" card and connect to that one to indicate an epic that cuts across multiple themes.

Forecasting at the Portfolio Level

The SAFe Roadmap at the portfolio level is based on estimating epics. The way to estimate Epics is through breaking them down into POTENTIAL Features (not necessarily the ones that will actually be developed) and then estimating these features in ART story points—the same estimation mechanism as well as scale used for the ART when planning PIs/iterations.

By using the same estimation mechanism/scale it is possible to use historical ART velocity to project/forecast how long it will take it implement a certain epic in the future. (See here for more info on the flow/forecast report.)

From a tooling perspective this process can be either done offline or online. Offline means using cards/excel/your preferred application and then updating the size field on the epic manually.

Online means going to the Connections tab on the epic, creating new connections, choosing the relevant Program board for the ART that will probably implement those features (if multiple ARTs you can go thru this process again for each ART board), create the features one by one, updating the sizes at that point or later, using "Save & Create Another" to stay in the context of the right parent and minimize your overhead creating those features. After you finish and return to the Portfolio board (use the elipses ... before the board name on the top left to do that easily) you will see the overall size of connected features on the epic child progress bar.

In either case, the next step is to aggregate the feature estimates back into the Epic estimate and update the size field on the epic. When choosing between offline/online consider whether you're introducing more waste by doing too much work for the epic too early or by doing work offline that you might repeat later on online. Typically, since this estimation happens so early in the process, doing it offline will both be more efficient time-wise as well as keep the program board clean of too much hypothesis and what-ifs that might not be prioritized anytime soon.

In any case at this point you will be able to see the different epics and their sizes in the Analysis/Portfolio Backlog lanes and together with the velocities for the different ARTs be able to forecast at a high level when an Epic can be started/finished.

Sub-lanes in the Implementation stage

ARTs/VSs pull a feature into Implementing when they start to actually realize an Epic. Initial decomposition into Features/Capabilities typically happens earlier to enable cost estimation but now it is fine tuned and actual Features are being pulled into PI Planning.

This is also where main ownership transitions to the Value Streams and ARTs.

From a tool-perspective this is the point at which the main activity moves to the Program/VS-level Kanban boards and working on the Epic's features/capabilities commences. The Epic will be connected to those child Features through the parent-child multi-board relationship. (See here for more on connections.)

Implementing can be one big binary stage—either in progress or done. Some organizations find it useful to provide some more visibility/transparency by adding stages like "System Demo" / "Delivered Marketable Value" and moving the Epic there when appropriate. This is useful because if not done this way, Epics will sit in the big opaque "implementing" bucket for a potentially long time, while providing very low visibility.

WIP Limit of the Implementation phase should be limited by downstream capacity—meaning the amount of epics the ARTs/VSs can effectively work on.

Epic tracking can be made easier by having the relevant person from the ART/VS become an assignee of the Epic (on top of the Epic owner).

In addition, it is useful to have a separate horizontal swimming lane for each ART/VS as it provides good visualization of what each ART is working on at the portfolio level. This is useful for Program Epics especially. Portfolio Epics that are by their nature implemented by multiple ARTs/VSs should reside in a “Cross-ART/VS” sub-lane.

Learning/Feedback at the Epic level

Another addition to the classic SAFe 4.0 Portfolio Kanban Board is a learning/feedback stage. This lane helps facilitate closure of the epic-level feedback loop—Have we achieved the success criteria? What have we learned while implementing this Epic that we can apply towards future Epics? Was this Epic indeed worth the investment?