Minimum Viable Product

Intent: Deliver a small portion of value in order to provide an early return on investment, and/or to allow lessons to be learned as quickly as possible

Proverbs:

    • You Ain’t Gonna Need It

    • Keep It Simple Stupid (KISS)

    • Test the water first

Also Known As:

    • Minimum Usable Subset

    • Must-Haves

Motivation: There are two separate and incompatible motives behind the delivery of Minimum Viable Product (MVP). Firstly, there is the desire to have an early Return On Investment (ROI). A complete product does not necessarily have to be delivered in order to be usable. A minimum set of features may prove sufficient to establish an adequate revenue stream. Alternatively, there may be a desire to test a hypothesis about the business environment or market. By delivering a minimum set of features that allows the hypothesis to be tested, lessons can be validated and wasted effort can be minimized. The establishment of an early ROI should not be a critical outcome if the testing of such an hypothesis has priority.

Structure: A backlog will consist of multiple items that are placed in a certain order for delivery. In addition to its order in the backlog, each item will be categorized in terms of its importance as a must-have, should-have, or could-have requirement. The must-have requirements will represent the Minimum Usable Subset of items needed for the product to either harvest a suitable Return On Investment from customers, or to allow important lessons to be learned about the customer market.

Applicability: The delivery of a Minimum Viable Product is appropriate when the provision of a subset of product features would be useful in its own right.

Consequences: The provision of a Minimum Viable Product is time constrained. Either a Return On Investment must be harvested as soon as possible, or a hypothesis must be tested and lessons learned before time and effort is wasted. By definition, the constituent items in a Minimum Viable Product are all must-have requirements. As such there can be no flexibility of scope. The risk of not delivering an MVP within a specified timebox is therefore high.

Implementation: Minimum Viable Product is not supported in Lean Kanban implementations except in the context of testing a hypothesis about the business environment or market, such as split A/B testing. An MVP representing collated requirements for a minimal marketable product is less viable where continuous integration and deployment is in use, and where each completed item is promoted to live without batching or staging. Minimum Viable Product is not recognized in Scrum, although a Development Team and a Product Owner may still plan for the delivery of a such an increment. DSDM recognizes must-have, should-have, and could-have requirements, and the delivery of MVP (called Minimum Usable Subset) is expressly supported.

See Also: