The Importance of Right-Sized Epics in SAFe

February 13, 2017 — Posted by Al Shalloway

This is part of our Tuning SAFe webinar series.  A recording of the webinar on this topic is available here

The Goal is to Realize Value Quickly

The Scaled Agile Framework® (SAFe) makes very clear the importance of building incrementally and prioritizing according to value (using WSJF, the “weighted shortest job first” formula). The goal is to realize the greatest value over the shortest period of time. This is one of the primary objectives in Lean-Thinking and it requires careful thought. It begins with right-sizing the “epics” in the portfolio.

While SAFe describes how this should be done, the importance of this is often overlooked in many implementations.  In particular, it’s not enough to compare which epics are most important, it’s critical to discover which parts of an epic should be built, deferring the rest for later.  SAFe describes this in their ‘Splitting epics’ section on their Epics Abstract page.  Unfortunately, the need and approach to this is often misunderstood. 

A common approach to splitting epics involves identifying the most important features. However, this feature-driven approach has some subtle implications that make alignment across programs difficult. It quickly leads to conversations about “how do we implement this feature?” instead of “what will give us the most business value?” A better approach begins with looking at business value, asking “what part of the epic will enable us to realize business value quicker?” The goal is always the fast realization of business value predictably, sustainably, and with high quality. All teams must align around this perspective.

Split Epics to Discover Highest Value

To illustrate this, consider “Market Segment / Customer / Class of User” mentioned in the Epics Abstract article. This approach considers which market segments or customer bases we are adding value to. By considering this first, we create a filter through which to look at the features of the epics.  Not only are some features not needed, but we’ll discover that many parts of required features can be deferred until future market segments are attended to. This is an important distinction that is too often overlooked. It means that we not only look to see which features are most important, but which parts of a feature are needed for the business value we’re trying to build. This gives us not only smaller epics but smaller features to implement.

The point of splitting epics into smaller epics is not to deliver less but rather to deliver something earlier. It is to identify the most important, highest value part of the epic and deliver that as soon as possible. And then to deliver the next most important part of the epic and deliver that. And so on as long as there is value to be realized relative to other opportunities.

Align to Complete Right-Sized Epics

Let’s take this one step further. By recognizing this “right-sized epic” as the first part of the epic to be built, all teams and trains should align to complete these right-sized epics in the order in which they are on the portfolio backlog. This is important to mention because trains do not always think about the sequence of completing work by value. More often, their selections are informed first by dependency requirements with other trains. But this poses several challenges. One challenge is that it delays feedback on whether the epic was completed properly, even if it is not going to be released right away.

Decompose epics into “right-sized epics” based on business value and then align everyone on completing those right-sized epics before going on to the next. This leads to greater feedback and greater value realization.  This goes beyond managing dependencies and encourages teams (and even trains) to work together on parts of an epic as they are being built.

Start and Adjust

SAFe is a great starting point. If you are experiencing any of the following challenges, it can often be solved by focusing on building right-sized epics.

  • Teams working on multiple epics simultaneously
  • Epics being larger than they need to be resulting in features being larger than they need to be
  • Too many epics being started due to the pressure of getting an epic started before completion of a more important one
  • Non-optimal train formulation because the epics running through them are not as focused as they could be
  • Dependencies are managed but teams do not collaborate as much as they should, resulting in high integration costs
  • Important items not related to development that are not attended to as quickly as they should be

The reason for this is the right-sized epic becomes something that everyone focuses on. One of the key benefits of SAFe over other approaches at scale is that it takes a holistic approach. In other words, SAFe does not lead to a mere collection of teams working together. Rather, they are guided with the intention of working as a whole. In the same way people in a team should align with the goals of the team, and teams need to align with the goals of the train, all of the teams and trains working on an epic need to align with delivering the most important epic as quickly as possible.

The smaller the epic, the more alignment can be achieved. Eli Goldratt, the creator of “The Theory of Constraints,” once said that “Often reducing batch size is all it takes to bring a system back into control.” Using right-sized epics is one way of achieving these smaller batches.

They also enable business stakeholders to more easily align across portfolios. This is because when large epics are involved, it is often difficult to get true agreement upon which epic is most important because some parts of each epic are more important than some parts of the other epic. By decomposing the epics and then doing WSJF on the smaller pieces, a better ordering of work to be done can be achieved. 

In Summary

There are four main reasons to do right-sized stories:

  • define and work on high-value items (avoid working on things of less imortance)
  • achieves quicker realization of business value
  • implementation is more efficient
  • teams are better able to align

You can find a more detailed whitepaper The Business Case For Agility where we refer to "Right Sized Epics" as Minimum Business Increements.

As always, if you can relate to this blog and are looking for assistance, please contact me at alshall@netobjectives.com

Al Shalloway
CEO, Net Objectives

Subscribe to our blog Net Objectives Thoughts Blog

Share this:

About the author | Al Shalloway

Al Shalloway is the founder and CEO of Net Objectives. With over 40 years of experience, Alan is an industry thought leader in Lean, Kanban, product portfolio management, SAFe, Scrum and agile design.



        

Blog Authors

Al Shalloway
Business, Operations, Process, Sales, Agile Design and Patterns, Personal Development, Agile, Lean, SAFe, Kanban, Kanban Method, Scrum, Scrumban, XP
Cory Foy
Change Management, Innovation Games, Team Agility, Transitioning to Agile
Guy Beaver
Business and Strategy Development, Executive Management, Management, Operations, DevOps, Planning/Estimation, Change Management, Lean Implementation, Transitioning to Agile, Lean-Agile, Lean, SAFe, Kanban, Scrum
Israel Gat
Business and Strategy Development, DevOps, Lean Implementation, Agile, Lean, Kanban, Scrum
Jim Trott
Business and Strategy Development, Analysis and Design Methods, Change Management, Knowledge Management, Lean Implementation, Team Agility, Transitioning to Agile, Workflow, Technical Writing, Certifications, Coaching, Mentoring, Online Training, Professional Development, Agile, Lean-Agile, SAFe, Kanban
Ken Pugh
Agile Design and Patterns, Software Design, Design Patterns, C++, C#, Java, Technical Writing, TDD, ATDD, Certifications, Coaching, Mentoring, Professional Development, Agile, Lean-Agile, Lean, SAFe, Kanban, Kanban Method, Scrum, Scrumban, XP
Marc Danziger
Business and Strategy Development, Change Management, Team Agility, Online Communities, Promotional Initiatives, Sales and Marketing Collateral
Max Guernsey
Analysis and Design Methods, Planning/Estimation, Database Agility, Design Patterns, TDD, TDD Databases, ATDD, Lean-Agile, Scrum
Scott Bain
Analysis and Design Methods, Agile Design and Patterns, Software Design, Design Patterns, Technical Writing, TDD, Coaching, Mentoring, Online Training, Professional Development, Agile
Steve Thomas
Business and Strategy Development, Change Management, Lean Implementation, Team Agility, Transitioning to Agile
Tom Grant
Business and Strategy Development, Executive Management, Management, DevOps, Analyst, Analysis and Design Methods, Planning/Estimation, Innovation Games, Lean Implementation, Agile, Lean-Agile, Lean, Kanban