Minimum Business Increment

A Minimum Business Increment (MBI) is the smallest piece of functionality that can be delivered that has value to the business in that it:

  • adds value for the customers of the business
  • provides valuable feedback that the right functionality is being built
  • provides valuable feedback that the functionality is being built the right way
  • provides functionality that can be verified as an increment that can be delivered
  • enhances the ability of the organization to deliver value in the future

A more common term for MBI is Minimum Marketable Feature (MMF) which was intended more for product development shops.  MBI is easier for IT organizations to use and understand. The Lean-Startup community sometimes call this a Minimum Viable Product (MVP) to underscore that one should come up with something as quickly as possible.  The Agile community sometimes speaks of a Minimum Viable Feature (MVF) meaning what can be built to validate we're moving in the right direction.  In any event, the MMF is a concept meaning - build the smallest thing possible to get value as soon as possible.  This can be for release, discovery of what to build, or validation of the path you are taking.

MBIs are created by first determining who your target audience is. Then, decide on the scenarios for this market for the business objective in question.  Focus on the minimum business increment for the scenarios in question - and that becomes your MBIs. Very often you will commit to a series of MBIs as the desired functional implementation you want to do for an epic.  By building and delivering them incrementally you get both value and feedback quicker - providing you an opportunity to pivot. 

We created the concept of the MBI to be used in established companies.  While conceptually similar to MVPs, they are more about the quick realization of business value than the discovery of what will be of value (although one must always be attending to this). 

Watch Driving From Business Value in SAFe, the Net Objectives to learn what MBIs are and how they can be used.  Although this webinar was from our 3rd Day of SAFe, it doesn't actually mention SAFe except in the title and is just as valuable whether you are doing SAFe or not.   You can learn more by reading More Insights on Epics Vs Minimum Business Increments,  our short article The Business Case for Agility or the more in depth chapter from our book Lean-Agile Software Development on the Business Case for Agility.

For Those Doing SAFeTM.

We use MBIs as the core of our planning event instead of epics or features because computing WSJF on either epics or features does not provide an effective ordering.  Epics are bigger than the actual work we will implement.  Hence, doing WSJF on an epic doesn't really make any sense since some (most?) of the epic will never be implemented.  Rather an epic can be thought of being a container for the features we will be creating.  But features, by themselves, often provide no value.  Features, even when having no technical dependencies on each other, often have business dependencies on each other.  This means that features often do not represent any value in and of themselves - that several features are required to deliver value.  When using features as the increment of value, teams often find they have to de-scope the features during the planning event to find the subset of the features that are needed in the timeframe allowed.  We have found it more useful to create MBIs from our epics and then do WSJF on them. Then, during the planning event, we already have the focus we need on the features to build.  That is, we define our features within the context of the MBIs from which they spring.  This makes de-scoping during the event unnecessary  - we've in essence already done this.  MBIs get us focused on both our target market and the minimum business increment we can deliver.  A focus on business value is a powerful thing.