Note: Disciplined Agile FLEX uses the term “Business Increment” instead of “Program increment” because the focus should be on delivering value to the customer not on the system the program is creating
A common challenge in Scrum is having a burn-down graph that looks like a hockey stick at the end of the sprint. That is, few stories are completed until near the end of the sprint. At the Program Increment level, the same thing can happen where business value is not realized until the end. Your goal is always to avoid “hockey stick” delivery graphs.
Planning events should focus on not only achieving what’s being planned for by the end of the program increment, it should attempt to get MBIs completed throughout the increment. This not only avoids the risk of not getting things done but lowers the cycle time of building things which eliminates waste.
Background
Many companies base their Agile Product Management on going from Strategy 🡲 Initiatives 🡲 Epics 🡲 Features 🡲 Stories. This causes a challenge in planning events, however, because ordering epics or features for completion doesn’t really make sense. In the case of epics, typically one part of an important epic is not as important as all of the parts of another epic. On the other hand, features are too small – typically they are an aspect of the value being realized. Even when a feature is releasable in and of itself there are usually other non-technology aspects that need to be considered.
SAFe® decouples implementation from release with its mantra “Develop on cadence, release on demand.” However, the focus of the PI is still on completing the PI much like the focus of a sprint is on its completion. While in sprints we should be focusing on the completion of stores, in program increments we should be focusing on the completion of realizable business value.
The concept of the Minimum Viable Product (MVP) has been re-introduced for startups. But the MVP was designed for the discovery of what is of business value. It also somewhat presumes alignment of the organization (startups are typically well-aligned).
The Minimum Business Increment
The backlog item to use to accomplish this should be the Minimum Business Increment (MBI) instead of features. The reason is that a feature, unless it is also an MBI, will not realize value when completed. We could get quite a few features done but have nothing to release.
Without a focus on MBIs it is possible, even likely, that features from different MBIs will get interwoven with each other and although we may complete our program increment have nothing releasable. In the same way that Work-in-Process (WIP) is managed in Scrum by focusing on completing stories, Program Increments need to focus on completing MBIs.
This shift results in an Agile planning and delivery process. Planning events usually focus on getting a release done by the end of the program increment (PI). But the focus should be on creating releasable value as quickly as possible – even if you don’t release until the end of the PI. This helps ensure you will have something of value at the end of the PI if things don’t work exactly according to plan.