Ever notice how sometimes doing one thing wrong can mess up a situation but doing one thing right doesn't necessarily fix this? That’s because there is an asymmetry in cause and effect. If often takes only one event to mess things up. But fixing one thing won’t fix the system when several bad events are taking place.

This is made more complicated when relationships between the parts of the system can’t be seen. This has led many people to abandon looking for what’s causing problems in knowledge work.

But this is throwing the baby out with the bathwater, so to speak. When we see actions that are causing problems, we can often discern if they are contributing to poor results. We don't know that stopping the action will help, but it might, and by attending to these negative activities one of 3 things will happen:
1) We’ll get improvement
2) We’ll see why we don’t
3) We’ll learn about a new relationship we hadn’t seen

This can lead to predictably good results. We always have to get feedback to see what's the result of any introduced change. But this feedback can be used to improve our understanding.

In my prior post (Understanding Simple Isn't Simple) I talked about what we really want is not "simple to understand or simple in design" but simple to use, simple to expand and/or change, and basically simple to be effective with.

This requires more than a few values and practices. As I've stated before - it requires a theory in order to guide us in learning what's effective. We also much be looking to go in the right direction. That is - are we adding value to our stakeholders? How can we quantify that?

Lean and Flow suggest that we can increase this by focusing on items of the greatest value and how to reduce delays and the waste they cause. Adding how to do this to whatever approach you are following may make its description less simple, but would definitely increase its effectiveness. 

The focus on simple to understand has resulted in many key, essential concepts being left out for many Agile adoptions. The assumption that people will figure these things out (e.g., MBIs, focused solution teams, value stream mapping) has been shown to be false for almost 2 decades now.

Let's stop looking at simple to understand and focus on how we can get to effectiveness

Simple is the most misunderstood word in the Agile community. 

There are several types of simple:
1) Simple to understand
2) Simple to use
3) Simple in design
4) Simple to expand and/or change

Simple to understand has little to do with anything. Few people understand how radios work, but they are very easy to use. A complex design may make something simple to use. Consider the camera in your phone compared to a camera 40 years ago where you had to consider film speed, shutter timing, aperture setting and focus.

Simple may require more skill to use – consider a unicyle. Also, consider a 27 speed bike with 2 derailers and 2 brakes. Apparently much more complicated than a 1 speed 1 brake bike. But consider how you can set the 27 speed to the speed most fit for a particular person. Then show them how to use the rear derailer, then the 2nd brake, then the front derailer. Easier to use at the start and easy to extend.

Finally, consider a luxury car vs a dune buggy. Which is simpler to drive? Depends upon where you are (i.e., is it fit for use?).

The question to ask is what simple do we want? Simple in and of itself may be irrelevant if it's not forwarding the purpose of what's being used.

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. The challenge lies in that who is describing what to build and who is building and releasing and supporting it are often different. The question then becomes what are we looking to build? How does the person or group deciding what to build describe this to the people that are building it?

We call this the Minimum Business Increment because:

1. (Minimum) it should be the smallest amount of value that is realizable because this speeds value realization and makes work easier to manage (transaction cost needs to be considered in this, of course)
2. (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)
3. (Increment) it represents an increment of value

Many people confuse this with an MVP. But, as we will see in the next section, these are not the same.

Minimum Viable Product (MVP[1])

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 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:

• 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 in more established companies, there should already be a good idea about the viability of the product or service 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)

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 facets 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.

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 possible is 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

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. It is also useful

• 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.

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.

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 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

Marketing

• 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.

Risks

• 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.

An important aspect inherent in MVPs and MBIs

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 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.

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.

There is a difference in how these are funded.

• 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.

Where and when to use MVPs and MBIs

(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.

The MBI as a Container

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.  We suggest using a template that specifies all of the information that is needed to create, deliver and realize value for the MBI.

Minimum Business Increment Template

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?

Requirements

• 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?

Miscellaneous

• Are there any risks associated with not completing this MBI?
• Are there other MBIs dependent upon completing this one?

The Difference Between the MMF and the MBI

One can think of the MBI as an extension of the MMF. Net Objectives coined the term “Minimum Business Increment” in 2006 after using MMF for about 6 months. There were two primary reasons for this. First, Many IT groups they worked with objected to the term “product” and “marketable” saying they didn’t market products. The second was the conflation with the word ‘feature’ in the Agile space.  Feature in Agile typically met some end to end value for the customer but not necessarily sufficient for a release. Because of these two challenges the following terms were tried:

• MMFS – Minimum Marketable Feature Set
• MMP – Minimum Marketable Product
• MMR – Minimum Marketable Release
• MVP – Minimum Viable Product
• MVR – Minimum Viable Release

We eventually set on the name “Minimum Business Increment” because of it being both descriptive and for it working for all types of organizations.

MBIs have since been expanded to include the MBI Template and information on who needs to build it. It continues to evolve as it is used in flow models of product development.

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.

[1] 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.

I keep finding that the conflation of empirical process control and empiricism to be confusing for many.

Ken created Scrum on the basis of empirical process control, then conflated it with empiricism and then dropped the statement about EPC from the Scrum Guide.

EPC is when you manage a process by adjusting your actions based on what happens. Basically "inspect & adapt." You don't go back and adjust your initial assumptions (Scrum's immutable roles, events, artifacts and rules) but just live within the framework. 

Ken learned EPC from chemical engineers. While the process varied, prior to see how to mix the chemicals was based on chemistry (theory) and for a particular situation. But transposing this type of process control to one of knowledge work is seriously flawed. Even if you get the right process in place, the needs will change as people learn. 

Applying EPC without also providing a theory to change what you're doing is less effective than applying it, providing sufficient theory to guide your process and doing double loop learning on the process.