Difference between MVP and Increment?

The concept of an MVP is not part of Scrum - the term "MVP" or "minimally viable product" (or similar phrases) cannot be found in the Scrum Guide.

I don't believe that an Increment must be an MVP. An Increment is usable, but may not contain "those features considered sufficient for it to be of value to customers, and allow for it to be shipped or sold to early adopters". The Increment, however, is required to be usable. Every Sprint, the Increment becomes more enhanced, preferably based on feedback by people using it. Eventually, it reaches a state that is an MVP and the Product Owner can choose to release it.

Consider that an Increment does not need to be released or deployed to production. Perhaps it's only placed in a test or demonstration environment for the purposes of eliciting feedback. Once it reaches MVP or specific features reach MVP (or beyond), that Increment or those features are deployed to production for real use by users. Until then, it lives in a non-production environment.

I don't believe that an Increment must be an MVP. An Increment is usable, but may not contain "those features considered sufficient for it to be of value to customers,

@Thomas Owens, IF the Increment should be Done, potentially releasable and the Scrum guide says the Product Owner may choose to immediately release it, then wouldn't it help get early customer feedback? Isn't the objective of every Sprint to create an Increment and deliver value? Isn't the delivery of value the reason why the items that were selected from the Backlog to be implemented?

Based on all the above, it appears the same to me but I guess in reality people tend to accumulate multiple increments and then call it MVP. 

IF the Increment should be Done, potentially releasable and the Scrum guide says the Product Owner may choose to immediately release it, then wouldn't it help get early customer feedback? Isn't the objective of every Sprint to create an Increment and deliver value? Isn't the delivery of value the reason why the items that were selected from the Backlog to be implemented?

I don't understand.

Typically, you would not release something before it was at MVP.

So, during the course of the Sprint, you create an Increment. Each Increment meet's the team's Definition of Done and is usable. Usable means that stakeholders can interact with the thing that you have created. You aren't just looking at diagrams or documents, but actual, tangible, usable work. By taking this work, or this Increment, and putting it somewhere where it can be used, you can elicit feedback.

Eventually, based on the knowledge of the market and feedback from stakeholders, you determine that the Increment is suitable for release. The Product Owner can, at this time, make the decision to release the Increment.

You can reach an MVP after 1 increment. It could take many. It's up to the Product Owner, likely with feedback from other stakeholders, to determine when MVP has been reached and if it's worth actually delivering the Increment.

I don't understand.

Typically, you would not release something before it was at MVP

@Thomas Owens, The below is the line from the scrum guide.

Development Teams deliver an Increment of product functionality every Sprint. This Increment is useable, so a Product Owner may choose to immediately release it.

How would a Product Owner release it immediately if it is not a MVP?

From the standpoint of what happens in reality with most teams, I agree with you on that you can't release until it is MVP, but per that line above, it looks like that is the goal.

I've heard Amazon, does multiple releases a day to production. Does that not constitute an Increment?

I've heard Amazon, does multiple releases a day to production. Does that not constitute an Increment?

I've heard Amazon, does multiple releases a day to production. Does that not constitute a MVP?

Also, I agree MVP is not a term used in the scrum guide. I am trying to relate if the concept of an Increment, as per the guide, is the same as MVP.

A real life example that recently took place.  We released an usable increment to stakeholders that did not constitute the MVP criteria.  The increment we released provided a sub-set of the requested MVP functionality but there was some pivotal feedback we needed.  The MVP could actually be satisfied in multiple technical ways.  We built a significant part that provided the stakeholders the "first half" of the functionality.  We needed feedback to determine if the path we had chose would be the one that the stakeholders wanted to use. The feedback we received lead to some modifications and a minor change in direction.  If we had waited until the full MVP was satisfied, we would have actually wasted more time and effort. The point at which we chose to release was a place at which the team felt was appropriate to gain important feedback.

So, can an increment be an MVP?  Absolutely yes.  Does is have to be a MVP?  Absolutely not.  Can an increment be released before the MVP is satisfied?  Yes. 

Hope that helps.

How would a Product Owner release it immediately if it is not a MVP?

I would not expect the Product Owner to release it immediately if it is not an MVP. The Product Owner may choose to release an Increment - the Product Owner is not forced to release an Increment at the end of a Sprint.

To be totally honest, I think the concept of releasing in the Scrum Guide is rather unclear. Coming from my background in regulated environments, releasing is its own process. In some cases, it requires independent verification from outside the Scrum Team - the Increment would need to be released to a different team before it can be released to end users. In other cases, the feature is so major that it requires the end user to perform validation or UAT that could take a couple of weeks (more than a Sprint), so an Increment is released to a UAT environment and managed there before it is released to production. It's not clear what "release" means, but "release" in these regulated environments usually has a specific meaning. To me, "releasing" in the context of Scrum is simply making the Increment available somewhere for people outside of the Scrum Team to use, regardless of if it's another internal team, a customer testing team, or end users in production. This gets further muddied if a single team has some work that needs to be held back due to needing independent test or UAT and other work that can go immediately into production in the next release.

I think there are three important things, at least in the context of Scrum in software development. The first is "working software". This is mentioned several times in the Manifesto for Agile Software Development - it's the primary measure of progress for the team and it's delivered frequently. The second is "valuable software" - things of value are delivered earlier. The third is stakeholder feedback - stakeholders get to interact (use, somewhere) with valuable, working software on a regular basis and give feedback to the Development Team and Product Owner that helps them understand what valuable software is so that it can be built.

MVP is just a milestone along the way. Eventually, your valuable, useful software is worth going forward with. Users can actually use it. It's mostly independent from Increments, although Increments of valuable, working software can help you gain a better understanding of what the MVP is and when it's worthwhile to take an Increment and release it.

So, can an increment be an MVP?  Absolutely yes.  Does is have to be a MVP?  Absolutely not.  Can an increment be released before the MVP is satisfied?  Yes. 

@Daniel Wilhite, Absolutely agree!! Spot on!

A product increment which fails to be minimally viable will incur a degree of waste or risk. Scrum is not prescriptive enough to forbid such an arrangement, and so not every increment has to be an “MVP”.

A definition I heard recently of an MVP is "the minimum amount of work needed to gain validated learning".

I dislike using the term "MVP" because nobody knows what it is, or at least, nobody agree on its meaning !

I like the way Henrik Kniberg switched it for "Earliest Testable" / "Earliest Usable" / "Earliest Lovable".

Cf. https://blog.crisp.se/2016/01/25/henrikkniberg/making-sense-of-mvp

Could an Increment be made up of several MVPs?

Hi, I'm more with Chris's point of view.

MVP supports your learning process while an Increment is the result of a Sprint. An Increment must be in a usable condition and potentially releasable. These have entirely different purposes.

A minimal viable product (MVP) supports your learning process. It is not the smallest product possible.  The "minimal" in MVP does not refer to the product, but it relates to the time and effort needed for a build-measure-learn feedback loop. 

MVP is not an end-goal and potentially a throw-away. It can answer product design or technical questions but it is principally a way to test a fundamental business problem: by creating a hypothesis about your problem, action or improvement and testing your hypothesis through an experiment. The feedback and learning from the result are useful for evaluating progress.  An experiment could be limited to a theoretical exploration but can also be a first product with missing features.  In each loop, you remain with the original strategic hypothesis or make a significant change. Iteratively repeat and refine this loop until you (incrementally) are where you want to be. Undesired variances are eliminated trough learning and self-correction. MVP, as I interpret it, serves more a compass.

The Scrum Guide doesn't mention MVP or the "Lean" build-measure-learn approach. The Scrum Guide suggests two other feedback loops: the Daily Scrum and the Sprint.  You could say that MVP is closer to the Scrum feedback loops than to an Increment. 

There is also this phrase in the Scrum Guide: "Specific tactics for using the Scrum framework vary and are described elsewhere."  MVP and the described build-measure-learn loop perfectly complement the Scrum framework as a practice. It is based on the same principles.  Transparency, Inspection and Adaptation are the same pillars that drive the empiricism in Scrum. Can we position MVP as a PO practice to turn ideas into products?  Perhaps not as a value maximiser practice but probably as a time-saver, risk avoider and strategic compass. Yes, you have to invest some time to create and measure the MVP but persevering too long with the wrong idea can cost more Development Team time.

I see differences too between the build-measure-learn loop and the Scrum feedback loops. Planning a build-measure-learn loop happens in the reversed order than executing the loop. You first determine what the problem is and what you want to learn. Only then you create a hypothesis about the issue you want to solve. Finally, you decide how to test the hypothesis, and only then you run the experiment. Executing the loop happens in the (opposite) build - measure - learn order.  Scrums' two feedback loops don't have this reversed planning approach.

So.. while having a lot in command with the Scrum's feedback loops and based on the same pillars, some parts of MVP and build-measure-learn approach are different.  I would catalogue it as a complementary practice to Scrum but different from an Increment. What do you think?

You could say that MVP is closer to the Scrum feedback loops than to an Increment. 

I think that makes the case for providing multiple increments throughout each Sprint, and for developing them as build-measure-learn MVPs. By doing so, the leap of faith taken with each Scrum feedback loop can be minimized, in so far as empirical evidence ought to thus be made available for timely consideration.

I think that makes the case for providing multiple increments throughout each Sprint, and for developing them as build-measure-learn MVPs. By doing so, the leap of faith taken with each Scrum feedback loop can be minimized, in so far as empirical evidence ought to thus be made available for timely consideration.

Not necessarily.

I'm not opposed to multiple Increments in a Sprint at all. In fact, it's very helpful. But an MVP needs to be, well, viable. An Increment does not need to be viable. My understanding is that an MVP is something that you would put into production. It may take several Sprints worth of work to create a set of work that is viable for production use and therefore an MVP, but your Product Owner may decide that it is appropriate for deployment to a test or preproduction or sandbox environment for validation and learning. The results of that learning could be that what you have truly is an MVP and can be promoted to production or it could be adjustments to the Product Backlog to move closer to an MVP in less time.

Steve Vb started this thread with three blurbs:

At the end of a Sprint, the new Increment must be "Done," which means it must be in useable condition and meet the Scrum Team’s definition of "Done".

This Increment is useable, so a Product Owner may choose to immediately release it.

The MVP has just those features considered sufficient for it to be of value to customers, and allow for it to be shipped or sold to early adopters. Customer feedback will inform future development of the product.

I'm writing to focus on the third blurb -- "The MVP has just those features considered sufficient for it to be of value to customers, and allow for it to be shipped or sold to early adopters. Customer feedback will inform future development of the product." -- as it is a quote from my first book. The content appears in the section, Potentially Shippable Product Increment. And the quote is immediately preceded by "The product increment may or may not be marketable. A Minimum Viable Product (MVP) is sometimes used to help test marketable ideas." And it's followed by a visual, similar to what's here: https://twitter.com/ScottGraffius/status/949820590499622912. 

As others have already noted, the MVP is a core component of lean. It is not part of Scrum. I included the content summarized here because the most common question I receive related to the Potentially Shippable Product Increment is how the MVP may possibly relate to it. Additionally, I've seen other instructors at Scrum Master and Product Owner training sessions briefly cover the MVP, although with the already-mentioned caveat that the MVP is part of lean, not Scrum. 

The Scrum Guide doesn't mention MVP or the "Lean" build-measure-learn approach. The Scrum Guide suggests two other feedback loops: the Daily Scrum and the Sprint.

@Steve Matthew

I think we can clarify this through examples.

Example 1

The product is an iOS app, with some kind of self-service functionality. The increment from the first sprint establishes the connection between the servers and the app, lets the user log in, change password, change avatar and similar basic stuff, but has no business meaning at all. Will the stakeholders want to release it? Even if they want, will Apple approve it?

Example 2

The organization has an internal system which is old, slow, circumvent and it is high time to replace it. The first (and the second, third, fourth, fifth, sixth...) increment covers the minority of the old system's functionality. Would the product owner want to release it? It certainly cannot replace the old system. Then, who will use it...?

Example 3

A company is working on a revolutionary digital payment product. In order to establish the basic functionality, it has to handle cards, connect to the SWIFT network, to systems of various clearinghouses worldwide, etc. It must pass the audit process of multiple international organizations and national authorities. In certain scenarios, when you change a single bit in your audited and certified system, your certification is void. Can you release all of your increments?

Getting back to the 'potentially releasable increment', in my view it has some technical and business message, something like:

1. The definition of done should not allow incurring technical debt. Just because the increment is not a release candidate, it does not mean that including hidden remaining work in an item which is claimed to be done is OK.

2. Product backlog items should be independent and meaningful on their own. Delivered requirements should not break the system.

3. As stated in the guide, the increment should be useable, inspectable. Otherwise, the discrepancy between what we want and what we have may go wide. Plus, needless to say, a 95% delivered code far from done and should not be included in the increment.

While there might be cases when the above criteria is very difficult to meet, the team should be aware that they are running a risk.

Thus, in the end, the MVP (which, as mentioned by many of you, is not a Scrum term but a business term enabled by agile software development) and the increment are not the same. The MVP is a version of the product which is either marketable or has all the features and qualities with which it can go to production. In other words, a 'milestone' or a 'phase' from a business point of view, with the old-school terminology. The increment is the outcome of the Sprint, in production-grade condition - but not necessarily with production-ready business content.

Hi all,

based on your definitions:

How can we measure the value of our webshop, if we do not release (to production) before we have reached MVP?

How can we measure the value of our webshop, if we do not release (to production) before we have reached MVP?

Right now it's nothing or negative, given that development costs have been incurred and no value has been earned.

Hopefully there will be unearned value in terms of potential market share and the closure of a satisfaction gap, but this has not yet been validated.

The only way to know for sure that you are working towards the minimally viable product functionality is to get continuous feedback from the stakeholders. The value is negative until you get feedback from stakeholders as they are the only people that can tell you if the work you are doing is valuable. They are the ones that need what you are creating.  The stakeholders tell you what is "minimally viable" but their needs can change quickly.  So what they told you was minimal viable on January 4th might not be minimal viable on February 2nd.  The identification of your stakeholders is extremely important.  Just as important is the identification of how to get feedback from those stakeholders.  This is not easy and it needs to be done well in order to succeed. 

Does this mean it has to be released to production in order to gain that feedback?  That all depends on how available your stakeholders are to be interacted with directly.  In some cases, you can only reach some of your stakeholders via production usage.  This is especially true for products created for mass consumption.