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
Take a deep dive into the state of quality with TechBeacon's Guide. Plus: Download the free World Quality Report 2022-23.
Put performance engineering into practice with these top 10 performance engineering techniques that work.
Find to tools you need with TechBeacon's Buyer's Guide for Selecting Software Test Automation Tools.
Discover best practices for reducing software defects with TechBeacon's Guide.
- Take your testing career to the next level. TechBeacon's Careers Topic Center provides expert advice to prepare you for your next move.
