Agile Glossary

Minimum Marketable Feature (MMF)

What is Minimum Marketable Feature (MMF)?

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: “Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.” The concept supports the idea that software you release to your customer, even if you’re doing it frequently should provide some added benefit and allow your customer to accomplish something they weren’t able to before.

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’s products and services).


Also Known As

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.

MMF is erroneously equated to MVP. 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.


Expected Benefits

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

Depending on the size of those features you may slice them into small user stories for delivery and feedback purposes across multiple iterations if you are using timeboxed iterations.


Common Pitfalls

Teams frequently refer to an MMF as a minimum viable product (MVP). There’s 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’s needs.
Teams stress the minimum part of MMF to the exclusion of the marketable part. The product delivered is not sufficient quality to generate the possible returns had the product been built with the appropriate level of quality.
Teams 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.


Origins

2004: Mark Denne and Dr. Jane Cleland-Huang introduced Minimum marketable features (MMF) in their 2004 book Software by Numbers: Low-Risk High Return Development.


Further Reading

Software by Numbers: Low-Risk High Return Development by Mark Denne and Dr. Jane Cleland-Huang.

Phased Releases

Add to Bookmarks Remove Bookmark
Add to Bookmarks Remove from Bookmarks
Add to Bookmarks Remove from Bookmarks

Thank you to our Annual Partners​

Join us today!

Agile Alliance offers many online and in-person events and workshops for our members. If you’re not currently a member, you can join now to take advantage of our many members-only resources and programs.

Get the latest Agile news!

  • This field is for validation purposes and should be left unchanged.

By subscribing, you acknowledge the Agile Alliance Privacy Policy, and agree to receive our emails.

Additional Agile Glossary Terms

An acceptance test is a formal description of the behavior of a software product, generally expressed as an example or a usage scenario. A number of different notations and approaches have been proposed for such examples or scenarios.
Test-driven development (TDD) is a style of programming where coding, testing, and design are tightly interwoven. Benefits include reduction in defect rates.
The team meets regularly to reflect on the most significant events that occurred since the previous such meeting, and identify opportunities for improvement.
A product backlog is a list of the new features, changes to existing features, bug fixes, infrastructure changes or other activities that a team may deliver in order to achieve a specific outcome.
An acceptance test is a formal description of the behavior of a software product, generally expressed as an example or a usage scenario. A number of different notations and approaches have been proposed for such examples or scenarios.
Test-driven development (TDD) is a style of programming where coding, testing, and design are tightly interwoven. Benefits include reduction in defect rates.
The team meets regularly to reflect on the most significant events that occurred since the previous such meeting, and identify opportunities for improvement.

Help us keep the definitions updated

Discover the many benefits of membership

Your membership enables Agile Alliance to offer a wealth of first-rate resources, present renowned international events, support global community groups, and more — all geared toward helping Agile practitioners reach their full potential and deliver innovative, Agile solutions.

IMPORTANT: We have transitioned to a new membership platform. If you have not already done so, you will need to set up an account on the new platform to establish your user profile.

When you see the login screen, choose “Set up Account” and follow the prompts to create your new account. You can choose to log in using your social credentials for either Google or Linkedin (recommended), or you can set up your account using an email address.

Not yet a member? Sign up now