MVP (Minimum Viable Product) and Agile

How do you work with MVP's within the context of Agile?

Let's start with some definitions; Eric Ries (the person who coined the phrase) describes MVP as "a version of a new product which allows a team to collect the maximum amount of validated learnings about customers with the least effort."

As per the illustration above, it sits snuggly in between being "viable" and "minimum". If you make it too "minimum", you get something your customer can't tell if they like it, hence not collecting the maximum validated learning. On the other hand, if you make it super "viable" (or so you assume), you spend lots of money and time building on assumptions before validating any. So the sweet spot is somewhere in the middle - minimum enough to not break your bank or time and viable enough your customers can validate your assumptions.

You also need to be aware of the mistakes usually made when calling something an MVP.

source: startupsanscoder

An MVP is not part of a product or service. It's a working product that's usable for the customer to use now.

For the record, let's define Agile as well (please skip if you know this by heart)

The best way to define Agile is through its 4 values, as shown above. It's a mindset founded on these 4 values. The mindset manifests itself into methodologies that you may have heard of by now; Kanban, Extreme Programming, DevOps and of course, the most popular of the lot - Scrum, which we will talk about in this article when applying MVP.

Scrum and MVP

The 3rd value (or 4th or 2nd, depending on how you see it, but let's not be anal) is "Working Software over Comprehensive Documentation". Again, the emphasis is on "working", which means having outcomes that can be seen and felt by stakeholders or customers. A regular working product that allows you to collect feedback before taking the next course of action.

An MVP is a new minimum product to put in front of a customer to see if they "like" it. Both definitions may seem similar and hence the confusion.

My perspective is that they are both quite different. There are two key differences;

Single sprint vs multiple sprints

In Scrum, developments are in short 2 - 4 week cycles called sprints. Each sprint will produce a Product Increment. An MVP development may span multiple sprints to realize a version that's testable with customers.

New to customers?

An MVP is only really applicable if the product is new to a customer. On the other hand, A Product Increment can apply to any product development, new or existing.

So what?

Well, to put it simply, it's about managing expectations. When you understand an MVP, you know that it requires good customer validation using clear metrics compared to Product Increments in Scrum, which does not need that sort of rigour.

You want your stakeholders and team to understand that MVP is only for new products, and it may involve multiple sprints to complete rather than expecting an MVP at the end of each sprint.

So in a single project, you may have to use both MVP and Increments and understand its difference.