Why Epics Are Not Used In FLEX

Looking at Portfolio and Product Management From a Non-Technologists Point of View

Epics have been a common term since the early days of Agile.  They are a very large story. But they have no real place on the strategic or portfolio management side of the value stream.  Business stakeholders tend to think in terms of strategies → initiatives → business increments. How to get from business increments to stories is clearer when we take business increments and decompose them into minimum business increments, then features and stories. Saying we have large stories just means that we should break them down. But working from epics causes many problems, as I’ll show in this chapter.

Figure 1 shows the suggested progression from Strategies to tasks

Figure 1: MBI’s role in the suggested sequence from OKRs to stories/tasks.

Why this is more effective than using epics

This Lean approach is more effective than using epics because it avoids confusion, incorporates the essential concept of the MBI, drives from business value, enables better sequencing of work based on lowering cost of delay, and enables using a flow model during the Planning Event.

It incorporates the essential concept of the MBI. The Minimum Business Increment (MBI) is similar to the original ideas behind the terms MVP (created by Frank Robinson and later redefined by Eric Ries) and MMF (defined by Denne and Cleland-Huang). The MBI is required to assure a focus on business value and business ability. The MBI results in features that are smaller and more valuable because they are focused on functionality that is needed now. This is better than the more common approach of simply pulling features from an epic without regard for value.

It drives from business value. Driving from business value involves identifying and defining MBIs based on the customers you want to target. It keeps the focus squarely value and who you are creating value for.

It enables better sequencing of work. Work should be sequenced in small increments based on the cost of delay. For example, sequencing work by epics has the problem that not all of one epic is more important than all of another epic. Even if you think about features in the epic and sequence those, features tend to be bigger than needed if they haven’t been derived from an MBI or MVP. The Lean approach attempts to think small right from the beginning.

More importantly is that calculating cost of delay on epics and features is not always effective nor does it even often make sense to do so. Consider the case of two different business stakeholders each advocating for the development of their own epic. Now, it is possible that all of one epic is more important than any part of the other epic. If this is the case, you would want to do all of Epic 1 and then work on Epic 2 as shown in Figure 2.

Figure 2: Doing epics in order of importance (more important work on the left)

The more likely case is that the epics are decomposed into MBIs and sequenced. Then it is possible to interleave the MBIs of the two epics. For example, in Figure 3 each epic has three MBIs. Each MBI has had WSJF run on them and the darker the color the higher the score,

Figure3 : Epics decomposed into MBIs with WSJF values depicted by color

Sequencing these MBIs by WSJF values results in an interleaved sequence shown in Figure 4. Some of Epic 1 (MBI 1.a) is more important than any MBI from Epic 2; but MBI 2.a is more important than the rest of the MBIs from Epic 1.

Figure 4: MBIs from different epics in order of importance (left to right).

This is a very important result for several reasons. Not only does it realize value more quickly, it also resolves disputes quickly. For example, it is easier for the owner of Epic 2 to wait just a little bit, until MBI 1.a is complete and then to start getting value rather than having to wait until all of Epic 1 is complete before getting any value. The point is that doing WSJF on epics is not as effective as doing WSJF on MBIs.

As a side note, doing WSJF on features that are not releasable on their does not make sense because value is not delivered until they are delivered with the other features required.

Figure 5: Features derived directly from epics.Parkinson’s Law states that work will fill the time allotted. Let’s consider how this applies to planning of Program Increments. If all of the features of an epic fit into the Program Increment, they may all be committed in the PI. But we may lose the potential of building a releasable part of the epic in a shorter time than the PI. Being able to do this lowers both risk (in case something takes longer than expected) as well as realizing value sooner when possible. If we use MBI to guide the work we’d do those features that are needed for the MBI first. You get more value focus.

Figure 6 shows the features defined by refining MBIs.

Figure 6: Features defined by within the context of the MBIs

We can now prioritize these in the sequence of the MBIs and use this sequence to choose from in the planning event.

Figure 7: Order of features within the context of the MBI they were derived from

Notice that all features from one MBI are together since they must all be done before any value is realized (since they comprise the MBI).

This is important because it:

  • enables value to be delivered quickly
  • has you work on smaller items
  • creates focus on what is needed
  • helps you avoid having almost all of some realizable value done but not getting all of it
  • lowers risk by completing things. Value is delivered after about 25% of the Program Increment has been done
  • has you prepare for the Planning Event by pre-sequencing MBIs and the features that belong to maintains line of sight from features and stories to strategies. them

Enables using a flow model during the Planning Event.

For large organizations, doing three-month Program Increments often represents a significant step forward in speed of delivery. However, most organizations should be able to build in smaller increments. One way of doing this is just having one- or two-month Program Increments. But another way is to run the program in a continuous manner using a flow model. This means to have a backlog of MBIs that are pulled when the teams required are available to do the work. In this way planning is an act of synchronizing how the teams will work together.

A note for users of SAFe. In the same way that Scrum is time-boxed with two-week increments, SAFe is time-boxed with its Program Increment. But it doesn’t have to work that way. The key to applying flow is to focus on finishing what is being worked on.