What are epics in SAFe?

The Scaled Agile Framework (SAFe) methodology is an industry standard framework for helping organizations scale agile and lean practices to an enterprise level. Use this template to establish a Program-level and Team-level tooling environment for the Essential SAFe 4.5 configuration.

Iterations

The template has one top-level Roadmap iteration, which contains one Agile Release Train (ART) iteration. Within the ART iteration, you deliver features in Program Increment (PI) iterations. Each PI iteration is further broken down into sprint iterations.

Roles

Work item types

The SAFe 4.5 Essential process defines the following work item types:

• Program Epic: A work effort constrained to a single release train, delivered by multiple teams, and spanning multiple PI iterations. Program Epics can represent business capabilities that address various user needs.
• Feature: Functionality that meets specific stakeholder needs. Features are sized and targeted for a program increment. Features bridge the gap between stories and epics. Like Program Epics, Features can represent business or enabler work.
• Story: A small behavior that can be implemented in an iteration. Like Program Epics and Features, Stories can represent business or enabler work.
• PI Objective: Describes a specific goal with planned and actual business value assessed for a Feature or Story. The PI Objective can be at the program or team level.
• Task: Defines a unit of work planned for a sprint and is estimated in hours. Tasks are typically linked to a Story by using a parent/child link.
• Defect: A bug, error, flaw in the implementation. Defects can be associated with a Story by using a parent/child link. Defects and Tasks associated with the Story are shown on the task board.
• Risk: Identifies an uncertain event, which can negatively affect the project. It includes an assessment of its probability of occurrence and impact.
• Retrospective: Used to capture the findings of a sprint retrospective meeting, or an Inspect and Adapt workshop.
• Learning Milestone: Marks specific progress points on the timeline and can be used to measure and monitor the progress and risk of a program.

Project area initialization

When you create and initialize a project area based on the SAFe 4.0 Program process template, a work item with the Summary of Post-Project Initialization is created. The Description in the new work item contains a link to a web page that describes tasks that the program manager or release train engineer should perform to get started working in the new project area. Two team areas are also created within the project area.

Work item templates

Project areas that are based on the SAFe 4.5 Essential process template include the following templates that you can use to create work items:

• Program Initiation: Use to create work items applicable when a program is first initiated.
• Program Increment: Use at the start of each Program Increment to create work items for typical events.
• Team Innovation and Planning: Use prior to each Innovation and Planning Sprint and for each team, to create work items for typical Sprint events.
• Team Iteration: Use to create work items for a SAFe team iteration.
• Solution Release: Use to create typical SAFe Solution Release tasks.

Work item calculated values script

Project areas that are based on the SAFe 4.5 Essential process template include the Weighted Shortest Job First (WSJF) calculated values script, which is used to calculate the WSJF value for Program Epics and Features. The template also includes Exposure Provider, Calculated Achieved Value, and Calculated Story Points calculated value scripts. For details about using calculated values scripts, see Configuring calculated value attribute customizations.

For additional details about the SAFe 4.5 Essential process template, navigate to the Templates tab in the web client. Click the Edit Process Description (

Many of my clients get confused about epics when moving to a Scaled Agile Framework (SAFe) and the SAFe Portfolio Kanban. But one day, in a recent training class, I stumbled upon an example that resonated with everyone and brought clarity to the model.

Once you understand the basics of SAFe, you can use this example to get your mind around the topic of SAFe epics.

Epic Burger and the Menus Value Stream

Let's say you work for the Epic Burgers fast-food chain, which has announced a new strategic theme to penetrate new markets.

You are given a Menus Value Stream, and begin your Horizon 3 (evaluating) work. Your value stream has been funded, and you agreed with Lean Portfolio Management (LPM) that 10% of your funding will be for Horizon 3 product exploration. The output of Horizon 3 is either a stop or invest decision in a solution.

Figure 1: The SAFe investment horizon model illustrating solution investments by horizon. 

Today the Epic Burger menu doesn’t target specific markets; it’s just a general menu of burgers, fries, chicken, fish, and milkshakes and other beverages. Your team believes it can determine a solution in a single sprint. You create an exploration enabler story on your board to explore ideas, charging your time to the Horizon 3: Evaluating bucket of the Menus Value Stream.

If you thought it would take more than a sprint, you would have created a feature instead. And if it would take more than a quarter, you would have created an Epic. That would be a big-time investment for no actual product. Just a decision to invest or stop. So this is your least likely scenario.

Your ideas include creating a kid’s menu, a senior’s menu, a coffee line to attract higher-income trendy guests, and an inexpensive $1 menu to attract college students. After comparing the various ideas, you determine that since no kids ever go to Epic Burger, having a kid’s menu would open a $2 billion market. Compared to the rest, you select this as the winning value stream solution in which to invest.

The Happy Fries MVP moves forward

You now have a brand-new product idea, code-named the “Happy Little Box.” You estimate that you’ll need $10 million in funding to create your new solution. You’d like to begin work on the Happy Little Box, but according to the SAFe Lean Startup model, you should think of a lower-risk MVP first. So you decide to create Happy Fries only as your MVP. To do that in a limited market will cost only $300,000.

Figure 2. Epics in the Lean Startup Cycle. 

Next, you write an epic for our agile board to create the Happy Fries MVP for your new Happy Little Box product. This is where people get confused: You will be closing this Happy Fries MVP epic once you’ve either pivoted to a new solution or persevered with the Happy Little Box product.

Depicted below is the SAFe 4.6 Epic Kanban where your Happy Fries MPV epic would live. Notice that the Happy Fries epic will be closed (done) once you evaluate its benefit hypothesis.

Figure 3. The Portfolio Kanban System. 

Wait ... why did you close that epic?

It was at this moment during my training class that the Epic Burger analogy was born. Product manager Matt Starr said, “Hold on! Why would we close the epic before we have created our new product? Wouldn’t that be like saying our $1 billion product was a Happy Little Box, but all we did was sell some french fries?” And so we chased this analogy the rest of the way.

The issue was this: We were thinking of the epic as the Happy Little Box epic. But it is in fact just the Happy Fries MVP epic. And that could be closed. But then how do you tie any future work to the product, Happy Little Meal?

It turns out that many folks want there to be a top-level container at the SAFe portfolio level for all work. In their minds, all work traces back to a portfolio epic, but this is not the intent of the SAFe model. It advocates for decentralizing portfolio decision making by funding value streams and then letting them self-organize on how to spend the money, subject to four guardrails.

Only if a guardrail faces change does the value stream need to collaborate with LPM (Lean Portfolio Management). The four guardrails are investments by horizon, capacity allocation, approving significant initiatives, and continuous business owner engagement.

Figure 4. The four guardrails that allow SAFe portfolio to decentralize portfolio decision making. 

What’s important here is that the top-level container of all work is not an epic. Epics are transient. They have clear start and end points and produce high value when closed successfully. So they are not suitable as top-level containers for all work for a product. The good news is that there is a top-level container, and that is the product itself.

Almost all modern agile tools allow you to set up “product areas” against which you allocate work in the form of epics, features, stories, and tasks. These “product areas” are your top-level containers. Work is then collected under them in the form of epics, features, stories, and tasks. And they don’t have to be in a hierarchy.

Agile release trains (ARTs) are feature machines that pump high-value features into production on cadence and release on demand. These features do not have to be parented to epics but are parented to products.

Epics are only created for very large work greater than one PI or for high-risk work to create an MVP of a new product. Here is a sketch that helped many of our teammates figure this out.

Figure 5. Relationships between value streams, products, epics, business cases, and features in SAFE. 

Here you can see that products are funded by value streams. Horizon 3 work is also funded by the value stream and can be managed as stories, features, or epics depending on how big the effort is. The most common, however, is a feature or story.

Horizon 2 work is usually an epic to create an MVP, but can also be a feature or story. But the MVP must be put into production to a subset of users to validate the benefit hypothesis. And therefore, if it fails, it must be decommissioned as some people are using it and probably liking it despite the failed benefit hypothesis.

An MVP must be in production, be in use by a subset of real users, be of good enough quality to grow, and prove or disprove its benefit hypothesis.

Products come out of Horizon 3 work, require an MVP, and then are grown by adding new features in Horizon 1. Horizon 1 is split in half: investing (more money spent, possibly as Horizon 1 epics), versus extracting (little money spent, small tweaks to keep it humming along, ops part of DevOps, usually as features, stories, or tasks). And all work traces to the product, not to some top-level epic in the portfolio layer of SAFe.

Again: The features and stories in "Horizon 1: Extracting" do not tie to some umbrella epic. They tie to the product. This has caused much confusion with my clients. They create “container epics” just to show the work at the portfolio level, but that is not useful in a decentralized value stream-funded portfolio.

Now back to Epic Burgers.

The lean business case for Happy Little Box

Now you have your first Happy Little Box Epic and you need to create an MVP to prove that your organization should invest big money into the $2 billion kid meal market. You go to Lean Project Management (LPM) and discover you are required to write a lean business case (LBC) for all Horizon 2 epics. LBCs for Horizon 1 epics are optional as determined by the value stream “troikas” (three roles that decide together: business, technical, servant leader).

The LBC explains both the big opportunity, but also what the MVP will be to help you decide to pivot or persevere. For the Happy Little Box, you land on this MVP: Let’s create Happy Little Fries and sell them in one location. If you can capture $200,000 in kid revenue in three months, you are really on to something. If you do, you’ll fund the product from the value stream. If you don’t, you’ll need to decommission the kid fries from the single location and decide whether to pivot or persevere on the Happy Little Box solution.

Another confusion arose at this point. What comes first? The MVP epic or the LBC? The epic comes first, even though it is a component of the not-yet-written LBC. If you look at the SAFe portfolio Kanban, the LBC is not required until the existing epic is in the Analyzing column. So it’s been around in the Funnel and Reviewing columns before the LBC was required! Think of it this way: You add the epic to you board so that you have the funding to write the LBC.

Figure 6. Portfolio Kanban System (v4.6). 

So the confusion is this: Hierarchically, the LBC contains the big idea and the MVP, so it felt to us as if it came first, but the epic on the board came before the LBC. 

MVP outcomes: Two possible scenarios

At this stage, your LBC is approved by lean portfolio management, and your epic has pulled the ART's product management into the portfolio backlog. Once capacity allows, the team with the free capacity pulls it into the implementing state and, eventually, the Happy Fries are ready for their debut as an MVP of the Happy Little Meal. You release them in your Detroit stores, then you measure and wait.

Will you hit $200,000 in Happy Fries sales in three months? Here are two possible scenarios:

Scenario A: After just one month, you hit $500K. 

The MVP is a smashing success! You close the MVP epic and decide to persevere. Note that in SAFe 4.6, you made that decision in the done state, but this changed in SAFe 5.0. (Hold on to that thought a moment.) Here is the interesting part: The LBC was for the Happy Little Box, but the MVP was for the Happy Fries. You close the Happy Fries epic, but the work continues in the form of Horizon 1 features or possibly additional epics. Perhaps you’ll create Happy Mains and Happy Desserts as two new features, but finding Happy Toys might be an epic due to the complexity. But that would be a Horizon 1 epic and not of much concern to LPM. Eventually in the distant future, you may have an epic to decommission the Happy Little Box, but for now it’s all investing or extracting.

Scenario B: The sales for the Happy Little Fries are pitiful.

The MVP is a failure. Again, it is time to close the epic and, in this case, you decide to pivot. But what do you pivot to? There are many choices. You could pivot to a different MVP, like Happy Little Desserts. Or you could pivot to a different value stream and build Happy Little Playgrounds to attract that $2 billion market. Or you could pivot to a different audience explored in Horizon 3: Senior Meals, Epic Café, $1 meals. And of course, you could abandon the Penetrate New Markets Strategic Theme altogether.

Note, in the SAFe 5.0 preview below, the pivot or preserve decision has been moved out of the “Done” column, and into the “Implementing” column. Further, it allows for LPM oversight even after the original MVP.

Figure 7. The SAFe 5.0 Version of the Portfolio Kanban. 

The Epic Burger example should help you better understand the relationships between value streams, products, epics, features, stories, and tasks. Epics are always broken down into features, but not all features belong to an epic: They belong to a product.

Size is the most important factor in choosing how to contain your work: Is it greater than a PI? Epic. Greater than a sprint? Feature. Less than a sprint, but still valuable to demonstrate? Story. Less than a sprint, but just a step toward bigger value? Task. Tasks are the only items without syntax rules and that don’t get demoed to anyone.

The big takeaway

So the next time someone asserts that all work must trace back to an epic, you'll know that that isn’t the model in SAFe, and you can create your stories without features and features without epics. Don’t create false containers that can't be closed just to trace them. Instead, trace your work to the products they support.

Are SAFe epics clear now? I welcome your questions and comments.

Keep learning