Before discussing Minimum Business Increments (MBIs) I want to discuss MVPs. MVPs are a useful concept but are different from MBIs and the distinction is worth knowing.
Minimum Viable Product (MVP)
Although Eric Ries didn’t originate the term in his book Lean Startup, most people now use his meaning of it. A Minimum Viable Product is a development technique used to develop a new product or website with just enough features to satisfy early adopters. Only after considering feedback from the product’s initial users is the final, complete set of features designed and developed . Here is the Lean Startup’s description of MVPs:
This is very useful; however, MVPs are not universally applicable.
The question is, what do you do in these situations when:
Of course, in most cases, the details of functionality are rarely known well in advance. But what about the value of a product or service? In times of innovation and new products, value is not yet known. It is not clear if the product or service is even viable in the marketplace. This is where the techniques of the MVP are most helpful.
But in more established companies, there should already be a good idea about the viability of the product or service and the value of an advance. You do not need the experimental approach of the MVP. This is what the Minimum Business Increment (MBI) addresses.
Minimum Business Increment (MBI)
In the situations where the value of an enhancement or new product/service is reasonably known, the concept of an Minimum Business Increment (MBI) is more useful. It focuses on the realization of business value quickly. It is not a reason to deliver less; it is a reason to deliver sooner.
An MBI is the smallest piece of functionality that can be delivered that has value to the business in that it. Here are some features of the MBI.
MBIs are created by first determining who your target audience is. This target audience may be external or internal. Then, decide on the scenarios for this market for the business objective in question. Focus on the minimum business increment for the scenarios in question – and that becomes your MBI.
A series of MBIs is often required to achieve the desired functional implementation of an epic. By building and delivering them incrementally you get both value and feedback more quickly which offers you the opportunity to pivot.
This business value should be based on what represents value for the business and its customers.
Value for the business may involve paying down technical debt, achieving steps in a Lean-Agile Transformations, improving platforms for a product or anything else that the business considers to be of value. It is up to the business to identify value.
Since MBIs are focused on the realization of value and not merely on deploying a feature, they must also describe all that is needed for full value delivery. This includes what would be required for ops, marketing, support and anything else.
Finally, any adverse effect an MBI may have on existing functionality must be incorporated into the MBI about to be built and not thrown over the fence to those who built the affected code. Determining how one MBI affects another is usually the responsibility of the business architect.
Click here to see examples of how to create MBIs.
MBIs are not just for the customer
MBIs can be for internal clients, not just customers. They can also be about improving internal processes and/or tools in the organization. In all cases, validating and delivering value as quickly as possibleis the intent.
Remember: these are Minimum Business Increments. The value realized may be for the business, not a customer. This does not just include paying down technical debt or Lean-Agile Transformations. In companies whose products are platform based, it could be improvements to the platforms.
Components of an MBI
MBIs must contain the value proposition for the client. But since they are about realization of value, not mere deployment, they must also contain what’s needed for full value delivery. This includes what is required for ops, marketing, support and anything else needed. In addition, any adverse affect an MBI may have on existing functionality must be incorporated into the MBI about to be built and not thrown over the fence to those who built the affected code. Determining how one MBI affects another is usually the responsibility of the business architect.
The purposes of MBIs
The purposes of an MBI include:
Finally, MBIs can be for internal clients, not just customers. They can focus on improving internal processes and/or tools in the organization. In all cases, the idea of validating and delivering value as quickly as makes sense from a business perspective should be followed.
MBIs and MVPs represent the bridge between the business and the development group. These are descriptions of the value to actually realize. This relationship is shown in the next two figures – first as they fit into the hierarchy of artifacts with the second showing where they fit in the value stream.
The importance of MBIs
The importance of MBIs cannot be overstated. The most effective way to lower cost of delay is to manifest value in small chunks. This also increases the efficiency of the development group. Consider the case where a team has three enhancements, each taking the same amount of time and each having the same importance. The quickest way to achieve value is if they work on one enhancement at a time, complete it, and then go on to the next. But they will very often be forced to start on all three. Figure 3 compares two scenarios of when work is done and when value is realized.
The interesting thing is that even if the Product Owners for A, B, and C know that A is more important than C, it is likely they won’t have the team do them in the optimal order. But let’s say A, B, and C can be sub-divided into MBIs. This enables the team to work on smaller enhancements and increase value manifestation even more. It also makes it easier to get the Product Owners to agree to the work being done serially. This is shown in Figure 4.
These results are even better than before. Of course, the decomposition into MBIs is insufficient. They need to be built by taking vertical, end-to-end slices in order to achieve quick feedback as described earlier.
The Minimum Viable Replacement (MVR)
We have already discussed using MVPs for new products and MBIs for enhancing existing products. Kevin Mireles has suggested another concept that is very helpful: The Minimum Viable Replacement, the “MVR.” This covers the situation faced by many large companies who spend a significant amount of their time replacing existing software. MVRs are for the increments used to replace an existing system in segments.
This does seem like a lot of terms. But it is important to avoid overloaded or ambiguous concepts. In a nutshell, MVPs focus on early adopters, MBIs focus on new functionality to a market that already exists or is somewhat known, and MVRs focus on how to control what is released. This is shown in Figure 3.
Targeting markets and increased alignment
When there is a choice in how to create MBIs, Increment’, it is useful to look at the different scenarios in which the new capability can be used. Very often each of these scenarios will have different market segments using them. MBIs can be selected on the basis of which scenarios and which markets should be targeted for maximum value delivery.
There is a powerful side effect to doing this. By creating MBIs that represent focused business value, they can be sequenced in order of importance to the organization. That is, those MBIs that deliver the greatest value soonest can be sequenced as a higher priority than those that don’t. This alignment of what is of greatest business value can also be used to align disparate teams in building things in this same order – thereby working together more effectively.
Note that MBIs are fundamentally different from epics. First, the Business typically does not know or care what an epic is. This is with good reason; for example, you can have strong feelings about a car but never care about how fuel injection works. An epic is simply an Agile construct that represents a “big story” without connection to value. MBIs are oriented toward business stakeholders and are tied to business value. An MBI, on the other hand, is an atomic unit of value and this enables it to provide deeper agreement on if and when it should be built.
Comparing MVPs, MBIs, and MVRs
Although there are many similarities to MVPs and MBIs, it is worth noting their differences.
Reason for investment:
In the customer market:
How to create the Mxxs:
Looking at the impact to existing offerings:
Looking at risk:
Other differences between MBIs and MVPsa re that MBIs
An important aspect inherent in MVPs, MBIs and MVRs
Even though MBIs are intended to be used when there is something already known about the market, it does not mean that you can assume what you are attempting to build with them is known up-front. It is still important to validate the MBI by working in small vertical slices. Consider Figure 2.
System evolution refers to when the software is being built from the system perspective, typically a layer at a time. Business evolution refers to when the software is being driven from the business perspective, that is, slices of demonstrable value. If you are going to use MVPs and MBIs, you are somewhat forced to write thin vertical slices of functionality. T his is a good thing. The difference is in how we go about deciding what functionality to write. With MVPs, you are more likely in a discovery mode, whereas with MBIs, the focus is more about value realized.
The Lean Startup movement
It is worth taking some lessons from the Lean Startup movement here. I’ve been discussing return of business value of mostly established products. The Lean Startup movement suggests delivering business value incrementally in order to determine which products actually have value. In other words, delivering part of a system, that may not be complete yet but which will provide some value to customers while indicating how much value the product can eventually provide is a useful consideration. The Lean Startup approach using Minimum Viable Products (MVPs) is a different, albeit useful, tact on incremental business value.
Both MBIs and MVPs have the same heritage of Denne and Cleland-Huang’s MMF. Having both in your arsenal of tools can be quite powerful. But it is important to know the difference. MVPs as described in Lean Startup are designed for startups and are focused around the discovery of new product value. MBIs are designed for all companies of any maturity and is focused on increasing value realized by the business. Both allow for pivoting as discovery of the true value of the product is delivered.
Using MVPs, MBIs and MVRs together
Here is what to do. Use MVPs when you are trying to discover if something is of value. MVPs are therefore used for innovation type products. MBIs are increments of value to be realized. You should have a good sense of what this value is before even starting the MBI. If you don’t, start with an MVP and then move to MBIs. MVRs are intended when you are replacing an existing system.
Note how the distinction of MVP and MBI brings clarity by avoiding overloading the terms. In some frameworks, MVP can sometimes mean the first one is for discovery and then after that, “MVP” is no longer for discovery. This is confusing. Starting with MVP and then going to MBI is much clearer.
The method of development will necessarily be different for these three types of increments. MVPs require short cycles and, probably, small teams. MBIs can work well at all scales. MVRs can work in a manner like MBIs but are driven by an existing customer market.
There is a difference in how these are funded.
(Thanks to Steve Edwards for comments that led to this section).
What happened to Epics?
Notice that business increments, MBI, and MVPs have taken the place of epics. Epics, as previously defined are not useful because they are such vague containers, and as mentioned in an earlier chapter, are not good candidates to use WSJF on. MVPs are included because they should be used when new products are being developed. However, you can see in the diagram that epics can be what we call business increments if desired.
See the chapter How Epics Are Used in FLEX for more information.
While I describe MBIs as the smallest amount of value that can be implemented and realized there is another, just as important aspect to MBIs. They also have to contain all aspects of what it takes to realize this value, such as marketing and support issues. In other words, MBIs are as small as they can be while still containing everything needed to realize value.
If it’s bigger than necessary, you will make flow harder to achieve. If it is insufficient, the value won’t be realized. An MBI must contain:
What’s needed to develop it
What’s needed for release / realization
It’s hard to argue that our value shouldn’t be defined this way, yet most frameworks don’t specify this. This is another reason that MBIs should be used for extensions to existing software and not MVPs.
Who are you building this MBI for?
Do they have another customer this is for?
Validating you have the smallest MBI
Is there any subset of the MBI that can be delivered sooner? Consider: geography, market segments, language, anything else you can think of.
Is the MBI larger than it needs to be because of deployment issues?
Are there any risks associated with not completing this MBI?
Are there other MBIs dependent upon completing this one?
Has the MBI met its definition of done?
What other groups are needed to enable the customer to realize value for the MBI?
What business architecture issues do we need to explore?
Are there any system or application architectural issues to be explored?
What development teams will be involved in creating the MBI?
What will Ops’ involvement be for this MBI?
How much notice must ops be given for them to complete their work when necessary?
What other groups will be needed?
Summary of an MBI
An MBI is a description of the minimum amount of business value which can be realized from a business perspective. It also details all the steps required for its release and realization.
 The term MVP has undergone several transformations. The term originally was coined by Frank Robinson. His original definition is fairly equivalent to our MBI and Denne and Cleland Huang’s MMF. Eric Ries usurped MVP for the Lean-Startup and SAFe has further redefined it by taking the Lean Startup’s perspective when they should have taken Mr. Robinson’s perspective. Many IT groups we worked with objected to the term “product” and “marketable” saying they didn’t market products. We eventually set on the name “Minimum Business Increment” because that’s more descriptive and works for all types of organizations.