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 valuable increment (MVI) 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

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 (MVI) comes in.

Minimum Valuable Increment – MVI

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 Valuable Increment (MVI). This renaming was done for IT departments that created software but didn’t market it. Over time, the MVI was enhanced to include not just what was to be built, but who was to build it as well as any acceptance criteria.

An MVI 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 MVI 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 valuable increment (MVI) 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 MVI.

  • 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 MVIs, we should consider the MVI as the document that is used to clarify what work needs to be done.

MVIs 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 valuable increment for the scenarios in question – and that becomes your MVI.

A series of MVIs is often required to achieve the desired functional implementation of an epic. By building and delivering the MVIs 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 MVI may have on existing functionality must be incorporated into the MVI about to be built and not thrown over the fence to those who built the affected code. Determining how one MVI affects another is usually the responsibility of the business architect.



Figure 2. Comparing MVPs with MVIs

MVIs are not Just for the Customer

MVIs 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 MVI could be improvements to the platforms. It could be about improving internal processes and/or tools in the organization.

Advantages of using MVIs

The MVI 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.MVIs contain all the work that is required to realize value. The scope of the MVI includes non-development aspects of value realization such as user documentation, market support, ops and others. MVIs 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.
  • MVIs ensure that at all levels, scope is always constrained by a focus on faster realization of value.Of course, when MVIs are initially defined, they represent the minimum chunks of business value that can be realized. But then, as the MVIs are decomposed into features and stories, the scopes of the features and stories are limited to that of the MVI. 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.
  • MVIs 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. MVIs 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 MVI. Plus, the features and stories are smaller since they are just implementing the part of the feature needed for the MVI. MVIs 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.

MVIs are fundamentally different from epics. An epic is simply an agile construct that represents a “big story” without making the connection to value. An MVI 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.

MVIs 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 MVI. The deferred analysis enables the team to release the MVI faster.

Why MVIs 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 MVIs provide answers for these.

The Bridge Between Business and Development

Figure 3. MVIs 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

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

By creating MVIs that represent focused business value, they can be sequenced in order of importance to the organization. That is, those MVIs 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 Valuable 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 MVIs 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 MVIs Together

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. MVIs are increments of value to be realized. You should have a good sense of what this value is before even starting the MVI. If you don’t, start with an MVP and then move to MVIs.

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

This helps when thinking about funding. For example, MVPs require short cycles and smaller teams. MVIs 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.
  • MVIs need to be fully funded. Remember that an MVI is the minimum valuable increment so this may not be much funding.

Why MVIs result in smaller features and why they should be used in big room planning

The use of MVIs enables having smaller features and stories. This is an important observation. This happens because when you create features from MVIs, you only have to have the functionality of the feature that is required by the MVI. 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 MVI. 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 MVIs

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

  • Meet the organizations definition of ready and have a definition of done
  • A statement of who will get value from the MVI
  • 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

MVIs 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 MVI. If this later approach is used, it’s important to reflect on the features after the MVI is defined and see if any part of them is required for the MVI. This is a useful step because sometimes the features when defined are larger than necessary before the MVI has been clarified.

Minimum Valuable Increment Template

This MVI Template is used to prompt questions when MVIs are being created.

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

Description of the MVI




Benefit Hypothesis

  • The anticipated benefit of this MVI
  • 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 MVI 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 MVI

  • Is there any subset of the MVI that can be delivered sooner? Consider: geography, market segments, language, anything else you can think of.
  • Is the MVI larger than it needs to be because of deployment issues?


  • Are there any risks associated with not completing this MVI?
  • Are there other MVIs dependent upon completing this one?


Upcoming Events

The Amplio Community of Practice (Free)

Learn More >>

Latest Learning Journey

The Amplio Development Masterclass

More Info >>

Amplio Consultant Educators

More Info >>

New Workshop

Register now >