Over a million developers have joined DZone.

Pattern of the Month: Minimum Viable Product

· Agile Zone

Learn more about how DevOps teams must adopt a more agile development process, working in parallel instead of waiting on other teams to finish their components or for resources to become available, brought to you in partnership with CA Technologies.

 “What we call chaos is just patterns we haven’t recognized. What we call random is just patterns we can't decipher.”
― Chuck Palahniuk


Lean and agile ways of working have a vocabulary of their own, in that certain words and phrases are given a precise meaning. One term that has recently come into vogue is "Minimum Viable Product". Along with other Lean Startup terms like "Pivot" and "Disruptive Innovation", this expression has become rather devalued and its precision blurred. For example, is it the same thing as a "Minimum Marketable Product" - see Roman Pichler's excellent article on this topic. What about a "Minimum Usable Subset"? Then again, it may be argued that an MVP is in some sense equatable to the "must have" requirements on a Product Backlog. Lean and agile practices may now be popular, but the rate at which their terminology has been co-opted far outstrips the pace of shared understanding.

In this article we consider the intent and motivation behind the usage of this particular term, and present it as an agile pattern. Patterns like this can help in agile adoption if they capture best practices and suitable acceptance criteria for applying them are worked out. This is a first draft of this pattern and so feedback is very welcome.

"Minimum Viable Product" is Pattern of the Month at agilepatterns.org

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
:

Discover the warning signs of DevOps Dysfunction and learn how to get back on the right track, brought to you in partnership with CA Technologies.

Topics:

Opinions expressed by DZone contributors are their own.

The best of DZone straight to your inbox.

SEE AN EXAMPLE
Please provide a valid email address.

Thanks for subscribing!

Awesome! Check your inbox to verify your email so you can start receiving the latest in tech news and resources.
Subscribe

{{ parent.title || parent.header.title}}

{{ parent.tldr }}

{{ parent.urlSource.name }}