SAFe Backlogs 1.3 - Epics

Now that you have all of those backlogs organized, you should build something with them! Now that you have all of those backlogs organized, you should build something with them!
PrevNext
Page 4 of 4

Epics 

Scope:
  1. Features: Solution development initiative
  2. Resources: No boundaries
     3. Time: No boundaries
Location:
  • Portfolio Backlog

Defining Aspects:
  • Lean Business Case
  • Minimum Viable Product

Description:

So far we've been using the iron triangle as a lens to talk about the scoping of these work items. The epic is where that paradigm breaks down. Epics represent huge pieces of effort that the org has decided to undertake. As such, they require some special handling, and all of it happens at the Portfolio Level.


Lean Startup Cycle:

The Lean Startup strategy recommends a highly iterative "build-measure-learn" cycle that fosters innovation and limits risk by reducing planning and budgeting horizons to smaller blocks of time. In it's nature, the Lean Startup embraces the core functionality of any agile practice; the "Plan-Do-Check-Adapt" of the Shewhart Cycle. In implementation, the cycle advises that you build the smallest thing that you can, get it in front of your target customers, gather their feedback and then elaborate the product from that point forward. This is directly counter to traditional project management practices that prescribe heavy up-front planning and design, with minimal feedback until late in project's life cycle.


Value Streams

Value Streams define how the user goes from initial contact with the organization to a transactional interaction; a purchase, a sign-up, etc. The Value Stream is a critical part of the life of epics because they provide directional governance on which epics the org should be pursuing in order to capture, retain and delight the customer. SAFe Program Consultants can lead you through a Value Stream Workshop to guide your group in identifying your streams. Since your ART's will strongly align with those Value Streams, you should be engaging an SPC to assist with this workshop as early as possible in your SAFe journey.


Epic Hypothesis Statement

As critical as the Benefit Hypothesis is to a feature or a capability, the Epic Hypothesis is just as critical here. The statement takes the form of:

​For ​<customers>
​who ​<do something>
​the​<solution>
​is a
​<something - the 'how'>
​that​<provides this value>.
​Unlike​<competitor, current solution, etc>
​our solution
​<does something better>.
​Business Hypothesis Outcome​-
-
-
​Leading Indicators​-
-
-
​NFR's​-
-
-

 The epic hypothesis statement is critical to scoping what is and is not within the scope of the epic's intended functionality. It should be clear and concise enough that throughout the epic's life cycle the statement can be used as a litmus test to ensure the right capabilities, features and stories are being worked on.

Minimal VIable Product (MVP):

Each epic should be written with an MVP designed to test out the Epic Hypothesis. How you define the MVP is subject to local context, but it should provide at least enough data to allow the Portfolio Level team members to make data-driven economic decisions about continuing to deliver the epic; the "Pivot or Persevere" decision.

Note that in the context of SAFe, the MMF and MVP are very similar. They both define the least amount of functionality needed in order to answer the critical question, "Did we build the right thing?" Their major difference is the scope of that functionality. An MMF answers the question for a single feature or capability, however an MVP answers it for an entire system.

Resources and Timebox:

Instead of scoping epics in the same manner as stories, features or capabilities, epics are only scoped by the "Pivot or Persevere" decision point. If you have crafted your epic correctly then it has, as its highest-priority deliverable, an MVP that will allow the Portfolio team to look at actual user data and determine if the epic is carrying its weight. Any capability, feature or story that doesn't directly drive the implementation of the MVP will delay the data from getting collected and analyzed; this should be avoided at all costs or you risk spending effort and capitol on functionality that may not be valuable.

At the end of each PI the Portfolio team will review data collected from the epic's MVP and determine if the organization should stop building that epic or continue. They may choose to pivot for several reasons:

  • The epic has delivered on its promise and is complete
  • Market changes have rendered the epic moot
  • Building the epic has uncovered something that we didn't know beforehand and that knowledge invalidates the epic
  • We've uncovered a better method to delighting our customer
  • Etc

In the event that the organization decides to persevere then that epic will be broken down into additional work items that extend its functionality or improves customer response to it. Those new work items will be fed into the funnel for development by the teams in upcoming PI's.

Regardless of the reasons, the Pivot or Persevere is the heart of the epic's lifecycle. Use this unique feature to guide the development of both the epic card and the actual product both.

Conclusion 

Throughout this series we've taken a long look at elements of the SAFe architecture that contribute to how we create and manage the work items, and how those items help our organizations create the right thing. In other words, we've walked through the framework to go from concept to cash. We've covered everything from the structure of levels and configurations down to the pieces of each work item that make them tick. In addition to a broader understanding of SAFe I hope you've also realized that none of these work items lives in a vacuum. Every part interacts with all of the other parts to create an ecosystem that we can harness to guide our product development.


Thank you for reading through this!

Additional Posts in This Series 

SAFe Backlogs 1.1

​When I am working with a client who is new to the Scaled Agile framework, or I'm delivering a training course for soon-to-be agilists, there's always a large number of questions about how the SAFe backlogs and work items relate to each other. These questions are understandable when you look over the Big Picture and see all of the different element...
https://allisonagile.com/index.php/blog/safe-backlogs1-1

SAFe Backlogs 1.2

The Hierarchy  This section may seem like its coming out of order; shouldn't we cover the specifics of each work item before we talk about their organizational structure? Maybe, but I'm coming at the topic in this sequence because I believe that where these work items sit in the Big Picture is such a huge part of understanding what they are. W...
https://allisonagile.com/index.php/blog/safe-backlogs-1-2


PrevNext
Systems Thinking for the Field Agilist - Download
SAFe Backlogs 1.2

Related Posts

 

Comments

No comments made yet. Be the first to submit a comment
Already Registered? Login Here
Guest
Friday, 29 March 2024
If you'd like to register, please fill in the username, password and name fields.