Disciplined Agile

Minimum Business Increments (MBIs)

Table of Contents

One of the cornerstones of agile is to release incrementally. Build something small, release it, learn from the release, make a pivot if needed, and repeat. This requires great clarity about what we are wanting to build and about how to describe that to the people who will be building it. To address this, use the “minimum business increment” (MBI).

An MBI is a clear 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.

  • Minimum. It should be the smallest amount of value that is realizable because this speeds value realization and makes work easier to manage while keeping in mind transaction costs.
  • Business. The focus is on delivering value from a business perspective. While it’s directed at the customer, it needs to be aligned to the business’ strategy. We call that “business value.”
  • Increment. It represents an increment of value.

It can be used in many different contexts: business, not-for-profit, services, products. It helps them realize the business value quickly. “The MBI is not a reason to deliver less; it helps deliver value sooner.” 

And while there are similarities with MVPs, they are not the same.


Minimum Viable Product (MVP)

Although Eric Ries didn’t originate the term in his book The Lean Startup, most people now use his meaning of it. A minimum viable product (MVP) 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 how lean startup describes MVPs:

  • Used for developing products for early adopters by focusing on learning what they want
  • Geared toward startups
  • Designed for the first time a product/service is released
  • Usually built by a small team that can already pivot

This is very useful; however, MVPs are not universally applicable. The question is, what do you do in these situations when:

  • You are an established company
  • You are building enhancements to an existing product/service
  • You are in IT and implementing known operating processes
  • The teams building it are not aligned and don’t work together well.

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 when a product or service is more established, there should already be a good idea about its viability and the value that an additional feature will provide. You do not need the experimental approach of the MVP. This is the situation the minimum business increment (MBI) addresses.


Minimum Business Increment (MBI)

The minimum business increment (MBI) applies when the value of an enhancement or new product/service is reasonably well known. It is the smallest piece of functionality that can be delivered that has value to the business. It helps the organization focus on realizing that value quickly.

Here are some characteristics of an MBI.

  • Adds value for the customers of the business.
  • Provides valuable feedback that the right functionality is being built.
  • Provides valuable feedback that the functionality is being built in the right way.
  • Provides functionality that can be delivered and which can also be validated as being useful.
  • Enhances the ability of the organization to deliver value in the future
  • Contains all of the pieces that are required for value realization. This includes any work required by documentation, ops and marketing.

Unless the organization is very small, the people deciding on what to work on will not be on the development teams doing the work. While both sides will be involved in creating the MBIs, we should consider the MBI as the document that is used to clarify what work needs to be done.

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 the MBIs incrementally, you deliver value and get feedback more quickly and this offers you the opportunity to pivot more effectively.

Value for the business may involve paying down technical debt, achieving steps in 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.

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.


MBIs are not Just for the Customer

MBIs can also focus on value for internal clients. The focus is on business value and sometimes this is value for the business. It is not always just for an external customer.

This does not just include paying down technical debt or agile transformations.  In companies whose products are platform based, an MBI could be improvements to the platforms. It could be about improving internal processes and/or tools in the organization. 


Advantages of an MBI

The MBI is the document that clarifies the work that needs to be done. Here are some advantages of this approach.

  • Provide an early descoping to high value. By doing this the organization can focus on manifesting the most important value. Smaller pieces are easier to manage. It is as Eli Goldratt, the creator of the theory of constraints, once said, “Often reducing batch size is all it takes to bring a system back into control.” Smaller pieces can be delivered more quickly. And, by focusing on the high-value pieces first, descoping early helps you avoid spending time on items of lesser value.
  • Ensure completeness to realize value. MBIs contain all the work that is required to realize value. The scope of the MBI includes non-development aspects of value realization such as user documentation, market support, ops and others. MBIs create the visibility throughout the entire value stream and provide clarity for DevOps as well.
  • Enable the ability to sequence the list of work to be done while attending to shared services that are likely constraints. This also enables avoiding starting work until you have the capacity to complete it.
  • Provide clarity of what to align around. All parts of the organization should be working towards defining, implementing, deploying and allowing for the realization of the most value as defined by the business stakeholders.
  • MBIs ensure that at all levels, scope is always constrained by a focus on faster realization of value. Of course, when MBIs are initially defined, they represent the minimum chunks of business value that can be realized. But then, as the MBIs are decomposed into features and stories, the scopes of the features and stories are limited to that of the MBI. And this means building only build is needed to realize value. This contrasts markedly with most agile methods of decomposition which start with epics and then pull the most important features out of the epics. While this does limit scope, the features are often built fully scoped instead of limiting them to a more focused target audience or purpose.
  • MBIs help to manage WIP. WIP is often thought of as the amount of work actually being worked on. But if a feature is started, then that entire feature is work in process. Same for an epic. MBIs have an influence on the amount of WIP because teams know they need to focus on finishing all of the stories in a feature and all of the features in an MBI. Plus, the features and stories are smaller since they are just implementing the part of the feature needed for the MBI. MBIs therefore minimize WIP by being smaller to begin with, having smaller pieces be decomposed from them (features and stories) and providing a higher view of what to finish.

MBIs are fundamentally different from epics. An epic is simply an agile construct that represents a “big story” without making the connection to value. An MBI is oriented toward business stakeholders and is directly tied to business value. It surfaces the conversations needed to get deeper agreement on if and when something should be built. For more information, please see How Epics Are Used in FLEX.


The Bridge Between Business and Development

MBIs and MVPs represent the bridge between the business and the development group. They speak from the business perspective about the value they will discover or get. They speak to the developers about what it takes to build and release and realize that value. They provide good line of sight from strategy to tasks (Figure 1).


Figure 1. MBIs and MVPs in the hierarchy of artifacts (click to enlarge).

Targeting Markets and Increased Alignment

When writing an MBI, consider the scenarios in which the new capability can be used. You may have scenarios based on the different market segments using the capability. MBIs can be created based on which scenarios and which markets should be targeted for maximum value delivery. This might result in several MBIs.

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.


Comparing MBIs and MVPs

MVPs and MBIs are similar in that:

  • They are mindsets
  • They use vertical slices of functionality to validate the work
  • They are customer centric.

But there are significant differences worth attending to:

Investment Reason

  • MVP: Discover if a new product is viable.
  • MBI: Get a return on investment by enhancing an existing product.

Customer market

  • MVP: Creating a new product for early adopter
  • MBI: Extending to a new market segment or solidifying offering to existing market segment


  • MVP: Have focused interactions with prospective clients
  • MBI: Market with existing marketing organization  through existing channels

Teams needed to create

  • Start with a small team focused on building just the MVP
  • Likely to require several teams coordinating together unless a product alignment already exists

How to Implement

  • Start with small features and expand.
  • MBI: Decompose into features that implement only the scope of the MBI

Impact on existing offerings

  • MVP: Little direct impact on existing products as this is new. May interact with existing systems.
  • MBI: Likely to interact with multiple systems.


  • MVP: May not have a viable market. Want to discover this early.
  • MBI: Enhancement may not be as valuable as anticipated. May affect other offerings.

Both MBIs and MVPs share a heritage with Denne and Cleland-Huang’s Minimum Marketable Feature (MMF). Having both MBIs and MVPs in your arsenal of tools can be quite powerful. But like with any tool, it is important to know when they are useful and what are the differences. MVPs as described in Lean Startup are designed for startups and are focused on the discovery of new product value. MBIs are designed for all companies of any maturity and are focused on increasing value realized by the business. Both allow for pivoting as discovery of the true value of the product is delivered.

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.


Using MVPs and MBIs 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.

This approach helps to make things clear by highlighting when we are in one state or another. MVPs when we are in discovery and MBIs when we are focused on realization. See Figure 2.

This helps when thinking about funding. For example, MVPs require short cycles and smaller teams. MBIs work well at scale.  

This helps when thinking about funding.

  • By definition, an MVP should be funded for the value of discovery. After it is built the decision to continue, pivot or stop should be made. It is also possible that an MVP is not intended for a full release but to a limited audience to determine its viability.
  • MBIs need to be fully funded. Remember that an MBI is the minimum business increment so this may not be much funding.

Figure 2. Using MBIs and MVPs from a strategic, innovation and solutions perspective (click to enlarge).

Minimum Business Increment Template

MBIs should be as small as they can be while containing everything needed to realize value. It helps to use a consistent MBI template across the organization that helps to capture what is required.

MBI templates should be tailored to the organization using them. Organizations will usually have more than one MBI template based on variations in regulatory requirements or involvement with hardware, etc.

Description of the MBI




Benefit Hypothesis

  • The anticipated benefit of this MBI
  • How will we evaluate if we’ve achieved this

Initiative This Came From 

Customer related

  • The target market for this
  • Who are you building this MBI for?
  • Do they have another customer this is for?


  • Use cases to describe the value
  • What’s needed to meet the organization’s definition of done

Architectural Issues

  • Are there any system or application architectural issues to be explored?
  • Has the business architect signed off on this?
  • What help from architecture will be needed

What’s needed for release / realization

  • Development teams needed
  • UX
  • Documentation
  • Marketing
  • Support
  • Shared Services
  • __________________

Ops Issues

  • Who will be involved?
  • When do they need to get involved?

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?

Related Resources