Project Management

Project Management Central

Please login or join to subscribe to this thread

Topics: Agile, Scrum, Teams
How do you decide on an MVP?
How should a team come to a decision on what a Minimum Viable Product (MVP) should look like, and what duration it should take to arrive at said MVP?
Sort By:
Page: 1 2 next>
For you to understand what your MVP should look like you need to understand your market. What are the key attributes your solution should have to satisfy their appetite? But be careful about taking shortcuts. Almost every requirement has some assumed requirements associated with it, which if left out of the MVP can have detrimental effects.

How long should it take to arrive at the MVP as in define or deliver? Defining a MVP takes as long as it takes but delivering it will depend on the attributes of the team and the framework used e.g. how long are the sprints, what is the velocity, etc. But for both defining and delivering an MVP the biggest driver will be the market. Where are you in relation to the competition? Can you wait for a 'better' MVP or will you lose opportunities? So I do not believe there is a one size fit all or even most answer.
Jonathan -

First thing is to know what an MVP is. It is a scientific experiment constructed to challenge a hypothesis about the viability of a new product or service. If you don't formulate the hypothesis well, the experiment will fail even before you start.

An MVP could be a throwaway afterwards since the primary objective is validated learning.

Duration or cost are driven by the nature and complexity of the product or service but you do want to maximize learning for the minimum investment point.

Kiron
Sometimes business is not clear what they want, it can be done by elicitation and some mock ups and sometimes by MVP. MVP is of course not having all needs of the business but its give them an idea how it will look like and perform. MVP cannot be done without stakeholder(s) approval. Duration varies because every business has different needs and complexity. For straight forward requirements it will take less amount of time and for complex projects it will require more time than normal.
Once business gets clarity and decided to move on, MVP is no longer in picture mean discarded.
The answer is highly dependent upon whatever internal definition of MVP is used. If MVP is viewed as part of a value discovery approach, then it can be surprisingly small. If MVP is viewed in the context of a nation-wide or global roll out, it will need to be significantly larger.
Understanding the market and key attributes for the solution, as Anton says, will undoubtedly help one understand what the MVP should look like.
Hi Jonathan,

find my / our approach here:

https://www.wps.de/en/aktuelles/blog-en/co...oduct-backlogs/

Nils
Key pupose of the MVP is to test a hypothesis, get fast response from market and to avoid developing the wrong product. MVP is the smallest set of features to test the market (mainly early adopters) in the shortest time possible. As said, it is not about creating a minimal product, but testing an initial hypothesis about certain features of a product solving a problem and creating value.
The team doesn't decide the MVP or the duration.

Assuming Scrum, the Product Owner is responsible for defining the MVP (or MBI), but doesn't do it in a silo. An understanding of the product users is needed, which often comes from outside the team.

The team is responsible for sizing the work. The number of sprints needed to deliver the the MVP is the sum of story points in the release divided team velocity. The duration for the MVP then depends upon the length of the sprints, or:

D = Ln
n = ?S_p/v

Where:
D = duration, or time (estimated) needed to deliver the MVP
L = length of sprints; number of weeks
n = number of sprints (estimated) needed to release the MVP
S = stories in the MVP
p = points for each story
v = velocity, or number of points that can be completed per sprint

The only thing the team decides is the estimate for the size of the stories.
...
2 replies by Kiron Bondale and Wayne Mack
Sep 23, 2020 12:10 PM
Kiron Bondale
...
Aaron -

I disagree that the team wouldn't have input into the content of an MVP. For example, the PO might have no clue about dependencies between work items which the team would be aware of.

I do agree that the final decision on what makes it into the MVP rests with the PO.

Kiron
Sep 24, 2020 8:07 AM
Wayne Mack
...
Developing an MVP is not an us vs. them situation. There needs to be an analysis of both market questions to be answered and technical approaches and capabilities constraints to answering the questions. The team consists of all parties working together bring their own sets of knowledge and experience. It is not 'I do this, you do that,'
Sep 23, 2020 10:58 AM
Replying to Aaron Porter
...
The team doesn't decide the MVP or the duration.

Assuming Scrum, the Product Owner is responsible for defining the MVP (or MBI), but doesn't do it in a silo. An understanding of the product users is needed, which often comes from outside the team.

The team is responsible for sizing the work. The number of sprints needed to deliver the the MVP is the sum of story points in the release divided team velocity. The duration for the MVP then depends upon the length of the sprints, or:

D = Ln
n = ?S_p/v

Where:
D = duration, or time (estimated) needed to deliver the MVP
L = length of sprints; number of weeks
n = number of sprints (estimated) needed to release the MVP
S = stories in the MVP
p = points for each story
v = velocity, or number of points that can be completed per sprint

The only thing the team decides is the estimate for the size of the stories.
Aaron -

I disagree that the team wouldn't have input into the content of an MVP. For example, the PO might have no clue about dependencies between work items which the team would be aware of.

I do agree that the final decision on what makes it into the MVP rests with the PO.

Kiron
...
2 replies by Aaron Porter
Sep 23, 2020 11:05 PM
Aaron Porter
...
I don't think we disagree. Of course the team has input into the work needed to produce the MVP. The product owner is responsible for "what" and the team is responsible for "how", but this doesn't prevent collaboration.
Sep 23, 2020 11:05 PM
Aaron Porter
...
I don't think we disagree. Of course the team has input into the work needed to produce the MVP. The product owner is responsible for "what" and the team is responsible for "how", but this doesn't prevent collaboration.
Sep 23, 2020 12:10 PM
Replying to Kiron Bondale
...
Aaron -

I disagree that the team wouldn't have input into the content of an MVP. For example, the PO might have no clue about dependencies between work items which the team would be aware of.

I do agree that the final decision on what makes it into the MVP rests with the PO.

Kiron
I don't think we disagree. Of course the team has input into the work needed to produce the MVP. The product owner is responsible for "what" and the team is responsible for "how", but this doesn't prevent collaboration.
Page: 1 2 next>  

Please login or join to reply

Content ID:
ADVERTISEMENTS

"Opera is where a guy gets stabbed in the back, and instead of dying, he sings."

- Robert Benchley

ADVERTISEMENT

Sponsors

Vendor Events

See all Vendor Events