MVP, Agile, Scrum - these terms are widespread in the software development industry and beyond. However, it became very apparent that there is a lot of confusion in the community on the relationship between these terms and concepts. We want to clarify them.

In the article, we explain Agile philosophy, reveal the relationship between Agile and Scrum, find out how Scrum and MVP are connected, and provide several great examples of MVP you have probably heard of. MVP in Scrum is a popular topic, we are sure it will be interesting.

Enjoy reading!

Scrum as an Agile methodology

Let’s start with two definitions:

Agile is a project management philosophy for software development with 4 core values and 12 principles that are cemented in the document “Manifesto for Agile Software Development” which was written by 14 CEOs, founders, ande engineers in 2001. It features an interactive approach to software development and its delivery to end-users. This approach benefits from incremental improvements of the software product when portions of the system are developed and delivered to final users at different times rather than building a final product with all possible features before its big release.

People came up with additional project delivery frameworks, practices, and methodologies based on the Agile philosophy. We can name some of them:

• Scrum
• Lean software development
• Extreme Programming
• Feature-driven development

Scrum is a widespread Agile methodology that is used for developing, delivering, and sustaining software products. Although it can be implemented in marketing, sales, and other fields, scrum is more often referred to software development. Scrum has comprehensive documentation Scrum Guides which contains Scrum theory: its values, team roles, and their responsibilities, artifacts, etc. It is a guide for managing the team during the development.

Although the scrum approach appeared in 1986 before the Agile Manifesto was published, the concept was altered to software development and recognized only in 2002 when two men wrote a book where they combined the Scrum idea and Agile principles.

If the Agile manifesto states that software should be developed incrementally, Scrum describes the exact way to define and deliver these “increments”.

Hope the difference between Scrum and Agile is clear now. Let’s go to the MVP concept. ‍
‍

What is MVP in Agile‍

Minimum viable product (MVP) is the version of the software product with functionality that is enough to satisfy the user's needs.

The concept was introduced in 2001 along with the Agile Manifesto publication, but it found the second wind as a part of lean software development framework in 2009 after Eric Ries published his book “Lean Startup”. Eric Ries stated that by using MVP you can collect validated learnings from customers:

The development of a new app starts when a team has guessed that their future product will be useful for users. However, they don’t know it for sure. And here a tricky thing lies: the team can release an app with a tremendous amount of features, two-way integrations, and cool design to find out that the market doesn’t need this awesome product.

Another way is to develop an MVP and gather customers' reviews after using the app. That approach helps the team to build a complete set of features that will be relevant for users.

Sounds impressive, right? Let’s move on.

How to build MVP in agile

The question “How to build MVP in Agile?” logically follows the previous abstract. However, building MVP in agile or building MVP in Scrum is quite an extensive issue that would be hard to cover in that article. So if you want to know about that more we offer you to read the article about MVP development steps or refer to the most comprehensive guide from Google.

Why build MVP [6 benefits]

‍

The benefits MVP brings are numerous. We want to mention the major: ‍

#1 Benefit: Early feedback from real users

The development of MVP takes less time than building a full-fledged product. Thanks to that, real users will get an opportunity to use your product and provide feedback earlier.

#2 Benefit: Better understanding of the market

Early feedback from real users implies that you get information about real customers’ challenges and preferences. So your further decisions will be based on the market needs, not your assumptions about the product value.

#3 Benefit: Less development cost

Here is simple mathematics: the development of 40% of all features for MVP cost less than the development of 100% features for a perfect app.

#4 Benefit: More satisfied customers

MVP is a part of Agile methodologies, so it shares the values and principles of the Agile Manifesto. The first principle of the Manifesto states that customer satisfaction is the highest priority. Following Agile principles will definitely bring you to more satisfied users!

#5 Benefit: Reduced risks

New projects are always accompanied by various risks that are directly connected with the time necessary for the development. MVP helps to cut project development timeframes, hence reducing risks. Some of them are listed below:

• failure to meet deadlines of a too big project
• vague budget limitations so you risk spending more money than was expected at the beginning
• focusing on wrong user needs during the development leads to the risk to get unsatisfied results because users wouldn’t buy the product as it was expected
• the risk of making wrong decisions because of wrong assumptions about the customers without real feedback from them
• the risk to waste budget and time on the development in case of total product failure on the market

#6 Benefit: Encourage incremental development

MVP is not a necessary element for being Agile and implementing incremental development, however, it’s a great first step that definitely encourages the team to use Agile methodologies.

However, this concept is not a panacea. It is an instrument that should be used correctly and only when necessary. Pushing MVP into every project without a clarity in reasons is not a good idea. Unfortunately, sometimes people tend to leverage technologies and concepts when they hardly get the hang of them.

Common mistakes in the MVP development

#1 Mistake: Believe that “minimum” means “poorly developed”

Sometimes companies try to benefit from fast product delivery and disregard that the product should be viable. Incomplete or untested products appear because of that confusion.

How to avoid that mistake: MVP is not equal to a poorly developed product - all features in MVP should perform smoothly and well.

#2 Mistake: Overbuilding an MVP

MVP is neither the product with the least functionality nor the final full-fledged product. It’s challenging to understand where the right number of features for MVP is. Minimum becomes close to maximum and MVP becomes a subject of the dispute between leaders who insist on including more functionality into MVP and developers who try to lessen the scope of work.

How to avoid that mistake: strictly define the functionality MVP should possess and assign a role that will be responsible for that list reconsideration.

#3 Mistake: No ideas how to sell the product

Without a clear vision, clearly defined values for users, and well-developed features, people will not pay attention to the new product and not buy it. The market is saturated with products - winning the heart of new users is a task to be done.

How to avoid that mistake: explore ways to message your core offer to final users.

#4 Mistake: A poorly-developed feedback system

Early feedback is the reason developers should tap into building MVP. However, data collection will suffer if there is no good in-build feedback system in place.

How to avoid that mistake: build a good feedback system. The system may be embedded in the marketplace or directly in your app - it’s up to you.

When we found out everything about MVP, it’s time to move to the combination of MVP and Scrum. And we used the word “combination” not accidentally because MVP actually has nothing in common with SCRUM except they both are connected with Agile philosophy.

MVP in scrum - difference between MVP and Increment

Let’s put everything on the table from the first lines. Ready?

MVP is not a part of Scrum, but MVP can go alongside Scrum and enhance its benefits.

Let’s get this sorted out.

Scrum methodology is fully described in the Scrum guide, while MVP was introduced as a part of the lean development approach. The Scrum guide mentions neither MVP nor lean development approach nor similar phrases.

According to the second abstract from the Scrum guide, “Each element of the framework serves a specific purpose that is essential to the overall value and results realized with Scrum”. Those elements are:

• Theory (core principles, have nothing in common with MVP)
• Values (no MVP in Scrum mentioned)
• Team and roles (not related to MVP)
• Scrum events (routine activities when you implement Scrum, MVP in Scrum is not mentioned)
• Scrum artifacts (which include product backlog, sprint backlog, increment)

As we can see, MVP in Scrum wasn’t mentioned. However, we highlighted the term “increment” since the meaning of this term can slightly resemble the meaning of MVP. Check it out.

The increment is a concrete stepping stone (usually software or some features) toward the product goal (usually a working product with some set of features). The increment must be done (which means there are no dependencies with non-developed functions), usable (bring value to users) and the responsible person may choose to immediately release it to get early feedback.

MVP, in turn, is software with a certain pack of working features that is enough to bring value to users so it can go public to gather early feedback from users.

These two definitions look similar, but in real projects, developers usually release several increments before calling it an MVP in Scrum. It can happen after one increment (rare case) or it could take many.

• Can MVP in Scrum consist of one increment? Yes.
• Is one increment equal to an MVP in Scrum? No.

Hope we managed to clarify the difference. However, there is one more fundamental misunderstanding of the MVP concept when this term applies to the situation when the product doesn’t exist at all. We are almost at the finish line, so take a deep breath and go.

MVP without a product - reality or nonsense?

Let’s start with examples:

If a company makes a video about the product when it doesn’t exist in the real world, is it an MVP?

If someone makes a product post on a crowdfunding platform without a real product and raises money to build it, is it an MVP?

If a game development company decides to develop a new game and makes a website with a fake demo video of the gameplay when the game development hasn’t been started yet, is it an MVP?

The answer to all questions is no.

In all cases above we are speaking about pretotyping.

Pretotyping comes even before prototyping the app. It is the easiest way to test an app idea quickly and inexpensively by creating a virtual image of the app in the form of a video, a post on marketplaces, or a website. The aim is to demonstrate the product to final users and validate its product-market fit before the project development actually starts. If a huge number of users wish to buy the app it means you should develop it.

Pretotyping can be simply explained with the next scheme: if you buy it, we will build it.

Finally, we want to demonstrate two great examples of MVP:
‍

Great agile MVP examples

‍

Spotify: listening is everything

Spotify app, the biggest audio streaming platform with over 381 million monthly active users, wasn’t even released to the public when it was developed! The MVP had 3 core guesses: people want to listen to the music without storing it on the local drive, that musicians and studios are ready to allow doing it legally, and that the internet connection can provide a sufficient bandwidth without lags and delays in listening. Based on that developers build a music player with only one option: finding and playing a few hard-coded songs. The early adopters of that MVP were the developers themselves, their families, and friends.

Minecraft: a sandbox video game

Minecraft, the best-selling video game of all times, allows users to gather natural resources, craft a wide variety of items, explore dungeons, defeat monsters, and even reconstruct the terrain and buildings from The Lord of the Rings universe.

This game with tremendous opportunities started as an ugly blocky 3d-landscape where players can smash blocks and move them. The development time of that version took 6 days of coding by one guy:)

So large Agile MVP examples are rare, however, there are plenty of less big projects where developers successfully implemented MVP. You can become the next example, and we can help to turn it into life.

Conclusion

Finally, there is nothing better than a clearance in terms and concepts, right?

As we have found out, MVP in Scrum isn’t mentioned, so it is not a part of Scrum. MVP is a part of Agile-based methodology called lean software development. It can go alongside Scrum and enhance its benefits a lot.

Thanks for reading!

SumatoSoft

This article was written with great expertise in the topic of writing since the SumatoSoft company provides software development services for startups, medium-sized businesses, and world-known brands, such as Toyota & Lexus, Beiersdorf to build their software products. We will be glad to help you in developing an MVP. Contact us to get a free quote!