Difference between MVP and Increment?

Last post 08:12 am August 17, 2019
by Lars Devocht
17 replies
Author
Messages
05:11 pm August 13, 2019

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.

From the first two lines from the Scrum guide, it appears the Increment and the MVP are the same. Am I understanding this correctly?

05:21 pm August 13, 2019

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.

05:38 pm August 13, 2019

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. 

05:49 pm August 13, 2019

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.

06:07 pm August 13, 2019

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?

 

06:39 pm August 13, 2019

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.

08:40 pm August 13, 2019

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.

09:33 pm August 13, 2019

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.

09:42 pm August 13, 2019

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!

10:24 pm August 13, 2019

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

12:41 am August 14, 2019

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

07:52 am August 14, 2019

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

10:01 am August 14, 2019

Could an Increment be made up of several MVPs?

01:00 pm August 14, 2019

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?

06:27 pm August 14, 2019

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.

06:58 pm August 14, 2019

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.

03:46 am August 16, 2019

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. 

08:12 am August 17, 2019

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.