Looking at Portfolio and Product Management From a Non-Developer 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:
Although we prefer the term ‘business increment’ to epic, FLEX can use either, depending upon what the organization wants.
Why this is more effective than using epics in the normal way.
This Lean approach is more effective than using epics to do WSJF on 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.
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.
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.
We can now prioritize these in the sequence of the MBIs and use this sequence to choose from in the planning event.
Figure 7: Features sequenced by MBINotice 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 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.
The next FLEX course is currently being scheduled in August in southern Orange County, CA. If you want to learn more about FLEX you can take an online course at the Net Objectives University. If you want to learn about how to adopt FLEX in your organization please contact the author, Al Shalloway