November 5, 2020, 8:30 a.m. to 6 p.m. EDT | November 6, 2020 – February 7, 2021, On-Demand | Online Conference
Please login or join to subscribe to this thread
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.
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.
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.
find my / our approach here:
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
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.
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.
Please login or join to reply