Skip to end of metadata
Go to start of metadata

Minimal Releasable Product

A MRP is the smallest set of features that must be developed before a release can be deployed into production. To count as being "deployed to production" the system must be used by at least one user set to perform real tasks within a particular workflow or set of operations.

MRP is similar but not identical to Minimal Marketable Feature (MMF) as defined in the book Software by Numbers. The primary difference is that while MMF focuses on maximizing the creation of business value over time, MRP is also focused on deployment strategy and feedback. On a meta level the difference between MRP and MMF is in the definition of business value. MMF focuses on the value of developed functionality while MRP takes a broader view and includes the value of early feedback and risk reduction. By reducing the risk of failure, MRP helps assure that real business value is delivered.

There is also a relation between MRP and a Minimal Viable Product (MVP). Both are focused on getting a release deployed as soon as possible. The primary difference is that a Minimal Viable Product is only concerned with the development of completely new products. The idea of MRP originally came from Replacement projects.

Balancing business value and MRP

A project that is able to release every three months or more often can prioritize solely based on business value. In practice though, many projects find it difficult to release every three months. This is especially true for the first release and even more so for Replacement projects. The Patterns described in this wiki help reduce the length of a release but they do so by reducing the business value of the release. This is the core trade-off that can be very difficult to handle.

The figure below is an illustration of how focus should shift from maximizing business value to reducing release length as a function of the release length of a project. Project A has a relatively short release length while Project B has a very long one. Project B should be working much harder than Project A on reducing release length. Project B should in many cases choose a strategy that provides lower business value if this strategy reduces release length. Project A should try to reduce release length but it should seldom sacrifice business value to achieve this.

glossary glossary Delete
Enter labels to add to this page:
Please wait 
Looking for a label? Just start typing.
  1. Oct 12, 2009

    I've never been comfortable with the term "minimal deployable entity." What about "minimal releaseable/shipped/shipable product/unit".

    1. Oct 12, 2009

      Minimal Value-able Entity ? But I agree, in a continous production scenario MDE = one simple change...

  2. Oct 12, 2009

    I have never loved it either. Have not found the right name yet. "Mimimal releasable product" sound like a better name. Conveys the fact that it should be worth releasing, not just possible.

  3. Oct 13, 2009

    ok, its now renamed

  4. Apr 06, 2010

    I'm not totally comfortable with the illustration - I have to think too much to understand it - so I've worked on coming up with something easily understood (and Tufte-compliant, I think). Here's the result (size-reduced, I can provide full size if wanted):

    The page text would have to be changed somewhat, since the Project A/B lines are not included here. Or the illustration would have to be changed, but I think the illustration is easier understood without the Project A/B lines in there.

  5. Apr 09, 2010

    Yes, this is probably a better visualization of the trade off between release size and other concerns. But there are two problems with it: the percentages give an impression of exactness that we do not have empirical grounds for, the diagram does not illustrate how a project can move towards the left of the diagram.