The Minimum Business Increment

The most significant recent addition to Disciplined Agile – the Minimum Business Increment (MBI) – can solve many problems we see in organizations. This article will focus on how adopting MBIs can solve a systemic problem in the Development Value Stream. Next week’s article will discuss MBIs and how they solve problems across the Development, Operational, and Support value streams.

Minimum Business Increments are a strategy for identifying the smallest value that a customer can realize a benefit. It is a container of information that bridges communication through the value stream, not just development.

Does your organization identify ALL the value-adding activities for the smallest next thing that provides value to a customer? If yes, you are better off than most. If no, the power in adopting MBIs is in the focus they provide. As the smallest things providing value, it is easier to sequence the work and eliminate dependencies. In addition, it enables understanding of the capacity and cost for all the people that will contribute to the value, again not just development.

The Development Value Stream Problem

One of the reasons I feel MBIs are such a valuable addition to Disciplined Agile is solving the issue seen in figure 1. Unfortunately, this is a familiar annual budgeting cycle for organizations around the world. We have all seen it. Identified ideas from when last year’s budgeting event began are the basis for a budgeting event conducted towards the end of the current year. Ideas are combined for product enhancement and submitted for evaluation—everyone politics for approval of their proposed project(s) for next year’s work.  When the budgeting event completes, we usually see a list of approved projects, ranging from small to big.

Figure 1: Annual Budgeting Cycle

This approach has many, many issues. However, I want to focus on and demonstrate how MBIs can solve one problem related to the scope of work in all these projects. So let’s move along in the timeline and see how the decisions from the budget event come to action. Figure 2 shows a few approved projects in my example; two big projects, a medium, and two small projects. The big projects, specifically the Direct-to-Consumer Sales Portal team (in blue), have many enhancements shown as features. Of course, there are other types of work, such as stories, paying down technical debt, and quality improvements, but let’s stick with the features.

Lots of ideas went into the budgeting process. They are in varying functional areas of the product, some related to each other and some not. They are packaged up into a sizeable work effort, spanning up to the entire year to complete. Other than being a big chunk of work that could be broken down into smaller pieces, do you see any other problems?

Figure 2: Example Project Delivery Based on Annual Budgeting Cycle

I have circled one of the more significant problems with red boxes in figure 3. The problem is that for a customer to get value from the three features in blue, the features in the four other products must be done. Hmmm, this is a problem! Of course, enhancements will be completed throughout the year, but if they all need to be done for our customers to get value, we will have to wait all year long until the big blue project is completed.

Figure 3: All the Development Value Stream Work Needed for a Customer to Realize Value

MBIs solve this problem. MBIs identify all the work needed to provide value as a package, not just one of the products that need enhancing, all of them. For example, the big red box in figure 3 is all work in the Development Value Stream needed; it is an MBI (next week, I will bring in the value-adding activities from the Support and Operational value streams). This work represents the smallest thing we can do that a customer will benefit from.

Figure 4: MBIs vs. Projects with Disparate & Disjointed Enhancements

MBIs solve the systemic issue of projects containing disparate and often disjointed enhancements. They bring focus to what is the smallest thing we can do, and that is the package of work. We no longer lump all kinds of work together as a “project.” We no longer have work waiting, aging, as other products have to get their lump of work done no matter what is in it before value can be delivered.

The MBI, a great addition to Disciplined Agile that I urge you to learn more about. For additional information, watch the recorded live event here: