MVPs and MBIs

This is a chapter from Amplio Development: The Path to Effective Lean-Agile Teams

Often reducing is batch size is all it takes to bring a process into control. Eli Goldratt.

Minimum Viable Product (MVP)

Although Eric Ries didn’t originate the term MVP 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.

Eric Ries defined the Minimum Viable Product (MVP) as a way to determine if a proposed new product was viable. A slice of functionality would be built, shown to, or used by a customer to move us forward in understanding what was needed. At some point, the product’s viability would be affirmed or denied.

In the Lean Startup, Eric Ries discusses how to discover if a new product is viable. He suggests starting with just enough functionality to gauge if customers will like it. He calls this a Minimum Viable Product, or MVP. The concept is to build an MVP quickly, get feedback, get the next slice of functionality, and repeat this until the product is ready to release as a new product.

Each MVP provides functionality, but may not necessarily be easy to use. Once the viability of the product, its usability may be increased. It’s important to realize that the MVP is a slice of functionality as shown in figure 1.

Figure 1: MVP as a slice of functionality.

Note for users of SAFe. The MVP described in SAFe bears no relationship to that of Eric Ries’ MVP. SAFe uses MVP ubiquitously which has it lose value it would have had otherwise.

Understanding the different types of requirements needed (ASG)

But epics, MVPs, features, and stories leave out the most critical need of them all – what do you call the artifact that describes the piece of functionality that extends an existing system? This is where the Minimum Business Increment (MBI) comes in.

Minimum Business Increment – MBI (ASG)

Most work by established organizations is done enhancing new products. This is quite different from discovering if you have a product. This was the intention of the Minimum Marketable Feature put forth by Denne and Cleland-Huang in Software by Numbers: Low-Risk, High-Return Development. Be clear, the MMF in Software by Numbers bears no resemblance to the use of it in SAFe. Around 2005 Net Objectives enhanced the notion of the MMF to be called the Minimum Business Increment (MBI). This renaming was done for IT departments that created software but didn’t market it. Over time, the MBI was enhanced to include not just what was to be built, but who was to build it as well as any acceptance criteria.

An MBI is a clear description of the minimum amount of business value that can be realized from a business perspective. It also details all the steps required for its release and realization.

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.
The focus is on delivering value from a business perspective. While it’s directed at the customer, it needs to be aligned with the business strategy. We call that “business value.”
It represents an increment of value.

It can be used in many different contexts: business, not-for-profit, services, and 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.

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.

Figure 2. Comparing MVPs with MBIs

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

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.

MBIs can create a focus for Agile teams by making it clear that these are the items that are to be released. Most teams amass stories and features to be released but it’s better to focus on the actual value intended to deliver. This also enables culling out parts of a feature that aren’t needed for an MBI. The deferred analysis enables the team to release the MBI faster.

Why MBIs Are So Important

Consider these questions:

How are you deciding which market segment is most important to you?
How do you decide what it takes to deliver value?
How do you avoid working on
How do you align teams that are required to deliver value?

Notice how MBIs provide answers for these.

The Bridge Between Business and Development (ASG)

Figure 3. MBIs and MVPs in the hierarchy of artifacts.

Line of Sight

It is important to see the successive decomposition described in Figure 2 as providing a “line of sight” for every artifact involved. For example, whatever level we’re at we can identify the next level up that it came from – all the way to the top.

Targeting Markets and Increased Alignment (ASG)

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.

The requirements for a Minimum Business Increment

Stated as a business objective
What capabilities are needed to implement it
What is the expected return
Must be able to calculate the cost of delay for it

MVPs and MBIs are similar in that:

They use vertical slices of functionality to validate the work
They are customer centric.
They are both built in thin slices

Using MVPs and MBIs Together (ASG)

Here is what to do. Use MVPs when you are trying to discover if something is of value. MVPs are therefore used for creating new 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.

Why MBIs result in smaller features and why they should be used in big room planning (ASG)

The use of MBIs enables having smaller features and stories. This is an important observation. This happens because when you create features from MBIs, you only have to have the functionality of the feature that is required by the MBI. When features are created from epics, they are not constrained by market segment or other factors, and the feature will be larger. This has features be smaller than they would otherwise.

This is critical to do in planning events. Consider when a team or group of teams does planning when they start with features not decomposed from an MBI. Let’s say they can pull in enough work for the timebox being used. While this looks good at first, this means they are actually building more than they need to get a release because the features are not as small as they could be. But now consider what happens when it appears they won’t get enough value pulled into the timebox. At this point, they have to thin out the features. This adds confusion to large planning events. And the quality of the features is certain to suffer.

Creating MBIs (ASG)

There is not a set way to create MBIs. However, there is an expectation of what an MBI will contain. MBIs should:

Meet the organizations definition of ready and have a definition of done
A statement of who will get value from the MBI
What capacities (teams) are required to implement it
What capacities (teams) are requires to release / support / market it
Any architectural issues required to build in
A description of the features required to manifest its value

MBIs can be built by first looking at the functionality needed and then writing the features to implement them. Or they can be built by identifying the features needed and combining those needed to comprise the MBI. If this later approach is used, it’s important to reflect on the features after the MBI is defined and see if any part of them is required for the MBI. This is a useful step because sometimes the features when defined are larger than necessary before the MBI has been clarified.

Minimum Business Increment Template (ASG)

This MBI Template is used to prompt questions when MBIs are being created.

It should be considered a starting point and should be adjusted for the organization using it.

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?