MVP, the Agile Approach to the Scope of the Project

When you hear about MVP is often exists among analysts. MVP is a Minimum Viable Product, that’s means a minimally executable product.

For the first time the concept of MVP appeared in 2001. Its author is Frank Robinson. In 2011 Eric Ries wrote his book “Lean Startup method”, which popularized this concept. In his view, MPV is a product with only a basic set of functions released to test a new business idea and assess the response of people using this solution.

The idea of ​​MVP is to get feedback at the early stages of product or service preparation and iterative adaptation of the product to the actual and real expectations of users. Feedback from the first customers about MVP should enable, among others, the following decisions:

  • whether the product arouses their interest at all, and if so
  • what functionalities are sought by customers or users of the product.

MVP is more a process than a product. The more that MVP is not a product with a minimum number of elements, but has basic functions sufficient to implement the idea.

Why am I writing about MVP?

Well, I encounter a situation many times when we want to do something quickly. We have an idea for a change in software, a change in the business process. And suddenly the change that was supposed to be small increases. In that way, we’re adding more changes or we want the process to be 100% automated. The list of requirements, stakeholders and budget is growing. Everything from a small change turns into something big and complicated. Unfortunately, not everyone is satisfied at the end. The effects differ from the original expectations.

For this reason, applying the MVP principles helps to reach the right and right results. MVP is based on the lean philosophy and assumes an iterative process of building, then measuring and learning, until the product fully meets the needs of stakeholders. MVP aims to avoid building unnecessary products regardless of whether they are new application functions, integrations or a changed business process.

Depending on the context, the MVP form may be different. Sometimes it will be several functions of the application connected with a “protein interface”, sometimes it will change the business process without changes in the applications. MVP in the software development process is necessary because it allows you to share an idea about a product and test it on its recipients or participants.

Workshops, models, creating working fragments of the solution, iterative construction of the solution helps to understand the needs of stakeholders. MVP must be a product that due to its function will be desired by the target group of its recipients. It’s a “must have” function, a set of minimal features and functionalities that the solution must meet.

On the other hand, you can’t fall into the trap of iteration. I know that by doing a dozen of workshops, there may be a moment when you will reach the point of thinking “just a one more thing” or other unnecessary action. It’s like a packing for the holiday your bag, at some point we take things that we might put on, provided that … ?

Does this mean that by building iterative we “bypass” these aspects ? Absolutely not. There will be situations when our MVP will not work. Let’s describe such situations so that the user (stakeholder) knows what to do. If these situations start to appear more often, than … in the next iteration, we will develop our product with this aspect.

MVP has one more limitation. In strictly regulated industries such as banking or insurance, this approach cannot be applied everywhere. Reporting, control and other aspects regulated by law may hinder the application of MVP to banking and insurance products. However, MVP can be used as an approach in marketing, sales or process optimization within such organizations.

In my opinion, MVP is an essential part of creating applications. It is such a healthy minimalism in which we do not waste resources and do what is exactly needed and necessary. MVP is putting minimal effort and money into preparing the change. Feedback builds new versions that reflect the specific needs of stakeholders. Doing what is exactly needed and necessary not only saves time and money, but also gives satisfaction to both those who create and use the solution.

And this kind of work and product I wish you 🙂

More from my site

  • Three Benefits of Use Cases I recommend each person to use the use cases particular in Agile projects. Below three are basic advantages that I think will convince you to use the use cases in Agile projects 1. […]
  • When is it worth modeling in UML? For some time, there has been a discussion about the value of modeling. Advocates of agile approach are not very happy to see models. Conservatives preferring the classic approach to the […]
  • Registration of Problems Identified During the Analysis I received an interesting question by e-mail: According to your knowledge, is there an object in EA that would be best suited for registering problems identified during business or […]
  • Prolaborate and Enterprise Architect A few weeks ago, in an article about Enterprise Architect Pro Cloud Server, I described one of the tools offered by Sparx Systems, which allows access to the model repository via a web […]
  • System Architecture On walls, boards and other surfaces, you do not see squares and rectangles connected with each other by lines. Next to them is the information of what these "squares are doing with each […]

Leave a Comment

Your email address will not be published. Required fields are marked *

Scroll to Top