Minimum Business Increment (MBI) Example

In last week’s article, I wrote the MBI is one of the most significant additions to Disciplined Agile. That article focused on a systemic problem in the Development Value Stream that MBI’s solve. So let’s take a look at how the MBI provides a communication bridge across all value streams – the Development, Operational, and Support Value Streams.

MBIs will vary in complexity. The example MBI I have chosen for this article is one with complexity.

An essential step in adopting the usage of MBIs is determining what information adds value, such as:

• How the MBI aligns to higher levels of outcomes
• Brief description of the MBI
• How you will measure the MBI’s outcomes
• What are the requirements for the MBI?
• Which value streams will contribute to creating the value?
• Who will do the value-adding activities needed for the MBI?
• Who will benefit from the value
• Which markets or segments do the MBI target
• Delivery risks of the MBI
• The relative size of the MBI in comparison to the other MBIs     

There are many formats for developing an MBI, one that I recommend is a business canvas. Figure 1 is an example I will take us through. I am not recommending this as the only approach, nor do I intend what is included to be a definitive list of the information an MBI needs – just one example of what is possible.

Figure 1: MBI captured in a business canvas format

In a lot of ways, I see how we work with MBIs very similar to User Stories. First, both need to be identified. Second, both need to have a written component as well as collaborative discussions. Third, with both, we need to know when they are ready to implement (definition of ready – DoR) and how we know they are done (definition of done – DoD).

 In this example MBI approach, you can see the brief description of the MBI and strategic alignment in the upper left quadrant. Figure 2 conveys how this MBI contributes to achieving an initiative. In this example and most situations, there will be many MBIs needed to accomplish an initiative. The initiative that this MBI contributes to achieving itself contributes to a strategic outcome. We decompose the higher-level outcomes into the next smallest bit of value a customer can realize.

Figure 2: Strategic Alignment of MBI

A critical piece of information that is often missing – how do we measure the value we are delivering. How do we order what we should do next without a measurable outcome? Think about the current organization you are supporting. Is it a success, at least in the Development Value Stream, that a release was pushed to production? Yep, I have seen this at many organizations, gold stars plus celebration – we delivered a new release. 

Ok, that is an important activity in creating value for a customer, but that is not a business outcome. Do we need a marketing campaign initiated, so customers know about a new bit of functionality? Changes in our operational areas, such as customer support or field workers at stores or branch locations, need to do something different? No, a release on its own and the contributions from the other value streams are not measurable outcomes. Instead, their aggregated completion sets the stage for an outcome to have a high probability of achievement. Figure 3 shows the outcomes of this MBI. For this example, the organization was data-driven with a rather sophisticated approach to forecasting desired outcomes.

Figure 3: Outcomes of this MBI example

In last week’s article, I stepped through how MBIs identify all the requirements for the Development Value Stream for a customer to realize value. Figure 4 ties that content along with what is needed from the Operational & Support Value Streams.

Figure 4: Feature level requirements of the MBI for all 3 Value Streams

Figure 5: Who is this MBI for, and where is it targeted

Which markets or market segments is this MBI targeted? Who is the customer that will benefit from this MBI? Figure 5 captures context for the market along with a note of future MBIs with market-specific enhancements. I almost always recommend using personas for understanding the customer.

Who will be needed to complete activities required to achieve the MBI’s outcome(s)? Do they have the capacity and funding to pull their part of the work? Figure 6 lists the teams for this MBI.

Figure 6: Who will be doing the value-adding activities?

Are there any risks in the delivery of this MBI? Figure 7 shows the identified risks. In Disciplined Agile, we want to remove dependencies via practices we can choose from and accommodate dependencies only if that is the best we can do. We also want MBIs to be as independent as possible. In this complex example, however, there is a significant dependency we must manage.  

Figure 7: Delivery Risk and Relative Size

The last bit of information in this example is relative size. 

For additional information, watch the following episode where I continue discussing the Minimum Business Increment (MBI) and how they solve problems across the Development, Operational, and Support value streams.