{"id":8031706,"date":"2017-06-27T14:46:01","date_gmt":"2017-06-27T21:46:01","guid":{"rendered":"https:\/\/test-agilealliance.pantheonsite.io\/?post_type=aa_glossary&p=8031706"},"modified":"2022-08-29T15:57:29","modified_gmt":"2022-08-29T22:57:29","slug":"mmf","status":"publish","type":"aa_glossary","link":"https:\/\/agilealliance.org\/glossary\/mmf\/","title":{"rendered":"Minimum Marketable Feature (MMF)"},"content":{"rendered":"

A small, self-contained feature that can be developed quickly and that delivers significant value to the user. The full term Minimum Marketable Feature (MMF) is not used widely in practice, however, the concept lines up nicely with the first principle behind the Agile Manifesto: \u201cOur highest priority is to satisfy the customer through early and continuous delivery of valuable software.<\/a>\u201d The concept supports the idea that software you release to your customer, even if you\u2019re doing it frequently should provide some added benefit and allow your customer to accomplish something they weren\u2019t able to before.<\/p>\n

The term marketable describes the idea that the feature provides value to the customer. Because value can be defined in a variety of ways including increasing or protecting revenue and reducing or avoiding costs, the MMF concept is applicable to both external products (intended for sale outside the organization) and internal products (for use inside the organization to support the delivery of the organization\u2019s products and services).<\/p>\n

\n

Also Known As<\/h2>\n

Many in the agile community have proposed variations on the term MMF, which in many cases alter the intended meaning of the concept. Examples include Minimum Marketable Product and Minimum Releasable Feature.<\/p>\n

MMF is erroneously equated to\u00a0MVP<\/a>. MMF is about delivering value to customers, whereas MVP is about learning more about the ultimate product. An MVP could range anywhere from not having any MMFs, to having a single MMF, to having several MMFs. They are not the same concepts, but both reinforce the idea that we should seek the minimum functionality in order to accomplish a specific outcome.<\/p>\n

\n

Expected Benefits<\/h2>\n

MMFs make the best unit of planning for releases. As James Shore described in his post about\u00a0phased releases<\/a>, if you can identify your product’s minimum marketable features and then prioritize the release of those features, you\u2019d be able to both earn and learn with the first feature while you work on the subsequent features.<\/p>\n

Depending on the size of those features you may slice them into small\u00a0user stories<\/a>\u00a0for delivery and feedback purposes across multiple iterations if you are using\u00a0timeboxed iterations<\/a>.<\/p>\n

\n

Common Pitfalls<\/h2>\n

Teams frequently refer to an MMF as a\u00a0minimum viable product<\/a> (MVP). There\u2019s not too much harm in this unless the team becomes too focused on delivering something without considering whether it is the right something that satisfies the customer\u2019s needs.
\nTeams stress the\u00a0minimum\u00a0part of MMF to the exclusion of the\u00a0marketable\u00a0part. The product delivered is not sufficient quality to generate the possible returns had the product been built with the appropriate level of quality.
\nTeams deliver what they consider an MMF, and then do not do any further changes to that product, regardless of feedback they receive about it and additional needs that the product could address.<\/p>\n

\n

Origins<\/h2>\n

2004: Mark Denne and Dr. Jane Cleland-Huang introduced Minimum marketable features (MMF) in their 2004 book\u00a0Software by Numbers: Low-Risk High Return Development<\/a>.<\/p>\n

\n

Further Reading<\/h2>\n

Software by Numbers: Low-Risk High Return Development<\/a>\u00a0by Mark Denne and Dr. Jane Cleland-Huang.<\/p>\n

Phased Releases<\/a><\/p>\n","protected":false},"excerpt":{"rendered":"

A Minimum Marketable Feature is a small, self-contained feature that can be developed quickly and that delivers significant value to the user.<\/p>\n","protected":false},"author":12,"featured_media":8067461,"parent":0,"menu_order":0,"comment_status":"open","ping_status":"closed","template":"","categories":[904],"tags":[],"class_list":["post-8031706","aa_glossary","type-aa_glossary","status-publish","has-post-thumbnail","hentry","category-business"],"acf":[],"aioseo_notices":[],"_links":{"self":[{"href":"https:\/\/agilealliance.org\/wp-json\/wp\/v2\/aa_glossary\/8031706","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/agilealliance.org\/wp-json\/wp\/v2\/aa_glossary"}],"about":[{"href":"https:\/\/agilealliance.org\/wp-json\/wp\/v2\/types\/aa_glossary"}],"author":[{"embeddable":true,"href":"https:\/\/agilealliance.org\/wp-json\/wp\/v2\/users\/12"}],"replies":[{"embeddable":true,"href":"https:\/\/agilealliance.org\/wp-json\/wp\/v2\/comments?post=8031706"}],"version-history":[{"count":0,"href":"https:\/\/agilealliance.org\/wp-json\/wp\/v2\/aa_glossary\/8031706\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/agilealliance.org\/wp-json\/wp\/v2\/media\/8067461"}],"wp:attachment":[{"href":"https:\/\/agilealliance.org\/wp-json\/wp\/v2\/media?parent=8031706"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/agilealliance.org\/wp-json\/wp\/v2\/categories?post=8031706"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/agilealliance.org\/wp-json\/wp\/v2\/tags?post=8031706"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}