Minimum Valuable Increment – MVI.

This is an excerpt from my Amplio Development: The Path to Effective Lean-Agile Teams. The concept of the MVI is an essential ingredient for achieving business agility. It is unfortunately missing in Scrum and SAFe as a named artifact which contributes to poor communication and implementation.

If you want to engage in an advanced learning experience, check out Amplio University , which helps you improve regardless of your role. By using advanced training methods, its six-month blend of live and recorded material covers the equivalent of 6 Agile workshops in a more effective matter and at a cost of about one workshop.

Most work done by established organizations is enhancing new products. This is quite different from discovering if you have a product. The Minimum Marketable Feature put forth by Denne and Cleland-Huang in Software by Numbers: Low-Risk, High-Return Development was about enhancing existing products. SAFe uses the term MMFs and references this book as well but the definition they use is not the MMF of Denne and Cleland-Huang.?

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. We later changed it to Minimum Valuable Increment so that it would relate to government IT departments as well.

An MVI is a clear description of the minimum amount of value that can be realized from the people using it. 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.
• Valuable.?The focus is on delivering value from a business perspective. While it’s directed at the customer, it needs to be aligned with the strategy that initiated the product or project.?
• Increment.?It represents an increment of value.

It can be used in many different contexts: business, not-for-profit, government, services, and products. It helps them realize the business value quickly. It is important to be clear that the MVI is not a reason to deliver less; it helps deliver value sooner.?

Comparing MVPs with MVIs

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 users of what’s being built. It helps the organization focus on realizing that value quickly. Of course, we must still validate that we’ve gotten it right and that it is of value. But the degree of uncertainty is less than with an MVP.

Here are some characteristics of an MVI.

• Adds value for the customers of the organization.
• Provides valuable feedback that the proper 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 useful.
• Enhances the ability of the organization to deliver value in the future
• Contains all the pieces that are required for value realization. This includes any work required by documentation, ops, and marketing.

Both product management and developers typically work together to create a description of an MVI.

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 initiative. 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 organization 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 business architects.

Figure 1. 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 organization. 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 an improvement to the platforms it uses. It could be about improving internal processes and/or tools in the organization.?

Advantages of using MVIs

MVIs are typically documented to clarify 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.?An MVI contains 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 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, the scope is always constrained by a focus on the 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 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 what 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 the 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 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 items of lesser value than what can be delivered sooner?
• How do you align teams that are required to deliver value?

Notice how MVIs provide answers for these.?

MVIs must be fully-kitted

The full-kit is a checklist that contains all of the elements that are necessary to complete a task or project. The concept comes from the Theory of Constraints.?

Before you would start a paint job you’d make sure you had all of what you needed - paint, drop clothes, brushes, tape, etc. Before you start a project you should make sure you have the full-kit. That is, what you’ll need to get it out the door.?

Too many projects are started too soon and end up waiting for parts of the organization to do what’s needed to get value consumed.

You don’t start working until you verify that all the boxes in the full-kit are checked.

This should be part of the Definition of Ready.

• It is not a phase gate.
• It is a way of avoiding starting something too early where it has to wait to get finished later.

It is not enough to build functionality to deliver. We must include all of the functionality and support information required for deployment. This would include, marketing, sales, support, ops, etc.

Amplio Sidebar: Lead the pack by being more Agile when change happens.

A case study by Al Shalloway

Many years ago I was brought into a company that wrote networking software to teach them design patterns and provide some coaching. The company wasn’t that large - I remember them having about 50-75 people in development. They asked if I would talk to their executive team for an hour and I said I’d love to. The teams wanted to be more Agile but management didn’t understand what Agile was.?

So I sat down with all the C-level folks and the director of marketing. I gave them a little talk about being more nimble and delivering more quickly. At some point the marketing person said that they needed all of the functionality and couldn’t build things in stages.?

I asked him to elaborate. He said that their customers did feature comparisons between their software and others and that they needed to win on features.?

Now, I didn’t know their business so I just started asking questions to see the reality of the situation.

I know a lot of times all features aren’t used so I asked him that. He responded “they’re not all used but they want them.”?

I asked “Do they discover that they don’t need them all? In fact, do they know up front they don’t need them all?”

He responded, “yes, but they want to have them just in case they need them.”

I didn’t know his technical background so I asked him “you do know that having more features adds complexity to the system and slows down future development?” He said he did.

So the issue now, by his accounting, was that people wanted to see all of the features in the system,that the people knew, however, that they wouldn’t use them all, and that having all of them slowed development down.

At this point we know the issues, but it’s not clear what to do. So I asked him:

“Would you rather be known as the company that has all of the features available, but many won’t ever be used, or would you rather be the company known for having the features you need and will provide new ones you need faster?”

He paused and considered this. It had clearly never been considered. He said he'd rather have the important ones and be able to create new ones faster.

This is the advantage of being Agile.

The Bridge Between Business and Development.

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

Line of Sight

It is important to see the successive decomposition described in Figure 1 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.

• 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?business 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 building only those parts of a feature that are needed for the MVI. This enables them to be built quicker and avoid waste that might ensure if we find we never need that part of the feature. This quicker feedback limits work in process as well.

This is critical in planning events. Consider when a team or group of teams starts planning 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 building more than they need to get a release because the features include scope not in the MVI. But now consider what happens when it appears they won’t get enough value pulled into the timebox. At this point, they must thin out the features. This adds confusion to planning events. And the quality of the features is sure to suffer.?

Creating MVIs

There is no one way to create MVIs. However, there is an expectation of what an MVI will contain. MVIs should:?

• Meet the organization's 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 required 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.

Going from Epics to MVIs.

One way to create an MVI is to go through this sequence.

First, make sure you want an MVI, that is, you are creating the requirement for enhancing/extending an existing product. Ask the following questions:

1. What part of the epic do you want to deliver soonest? Consider different subsets by looking at one of the following:
2. What do I need to
3. Must allocate cap ex and op ex (learn more about cap ex and op ex by going here ).
4. What are the features in the context of this MVIs