Jonathan LeeBusiness Development Manager| Symphony Communication Services LLCSingapore, Singapore, Singapore
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? Saving Changes...
Anton OosthuizenSenior Business Analyst / Project Manager| Self EmployedPretoria, Gauteng, South Africa
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. Saving Changes...
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.
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. Saving Changes...
Wayne MackRetired| RetiredSouth Riding, Va, United States
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. Saving Changes...
Marcus UdokangProject Manager| Aivaz ConsultingCalgary, Alberta, Canada
Understanding the market and key attributes for the solution, as Anton says, will undoubtedly help one understand what the MVP should look like. Saving Changes...
Nils HyomaAgile Coach| Novatec Consulting GmbHHamburg, Hamburg, Germany
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. Saving Changes...
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,'
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.
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. Saving Changes...
Community Champion
