Disciplined Agile

Practice: Decomposing a Capability into MBIs

Why to Do This Practice

A capability is composed of one or more minimum business increments. Decomposition commences with identifying the potential MBIs within a capability.

The objective of this practice is to identify the MBIs within a capability.

An MBI is the smallest grouping of functionality that a customer or stakeholder will be satisfied with receiving. Sometimes this is stated as “that they will pay for,” which is correct when payment is the appropriate response. However, sometimes other forms of satisfaction are involved; for instance, for a stakeholder who is a government regulator, satisfaction may be by way of issuing an approval.


An example of decomposing into MBIs is the “swimming pool MBI.”

List all the conceivable features of a swimming pool: filter system, diving board, slide, lights, robot cleaner, steps, concrete apron surrounding it, pool edge bar, and some non-functional features such as shape, depth, length, width, color. This is an impressive list of needed and wanted features. Do all of them have to be delivered in one big package though?

What if the homeowner has any limitations to the budget? Or what if they want to get the pool as quickly as possible? What is the smallest set of features that would satisfy the homeowner in a first pass?

If that can be identified and delivered, then everyone wins: The homeowner doesn’t have to save up as much money before starting the project and they get to start using the pool sooner.

This example shows several important things about MBIs:

  • MBIs are all about understanding the customer or other stakeholders. What will the stakeholder recognize as benefiting them? That is what we want to deliver to them; not some pieces they can’t use yet. For instance, shipping a homeowner a pool slide, by itself, before the pool is built, is unlikely to make them happy. Indeed, they must now try to find a place to store it, which just brings extra work and no benefit. An irritant.
  • This same question can be asked about features: Will the stakeholder appreciate it if they were to receive feature X by itself? Or some group of features that do not add up to usable value for them?
  • MBIs can often best be identified by moving down one level of detail and thinking about potential features that might go into the MBI. (like the pool features)
  • MBIs allow delivering more value to the customer, earlier; not less (as you might assume from the name “minimum”). Delivering just the minimum amount means less work and less time between the “order” and the “delivery” of useful functionality. It also often allows earlier benefit; the customer receives something they can use, as soon as possible.
  • MBIs are all about boundaries. What is absolutely needed to make the MBI into something the customer finds valuable? What can we leave out, and the customer will still be pleased?

Who Does This Practice

MBI requirements are created from both business capabilities and architectural capabilities.

  • Business MBIs. Product managers write business-functionality MBI requirements.
  • Architectural MBIs. Enterprise architects typically write architectural MBI requirements. As needed, they can enlist the support of other architectural stakeholders (e.g., technology owners, technical leads). Sometimes it is difficult to identify what a self-contained package of architectural value looks like, especially when all the stakeholders who might take advantage of an architectural capability are not yet known. In this case, use judgment to identify the minimum useful amount of functionality to deliver, and make that the MBI.

What To Do


Inputs to this practice include:

  • A capability statement in a portfolio backlog, approved for further development.
  • Consultation and supporting information from project managers, product owners, and stakeholders such as customers, customers’ customers (generally coordinated with the first-line customer’s agreement), users, and regulators.


1. Given a selected capability, obtain all written and verbal information about the capability from which you will be developing the MBI.

  • If the capability has not already been thoroughly defined, identify all major stakeholders and develop channels to allow communicating with them as you define the MBI.

2. Develop a deeper understanding of the archetypal stakeholders of the capability who will now be the focus of the MBI. This includes both their wants (things they consciously know about already) and needs (what they may not consciously recognize yet). If no archetypal stakeholders have been defined for the capability:

  • Develop archetypal stakeholder profiles.
  • If you do not have access to the stakeholders, then
    • Find surrogates for them; such as people who previously worked in their industry and roles, and interview them
    • If no surrogates are available, read about their industry and roles

3. Choose the most important stakeholders to be the focus of the MBI requirement, and the value that will be delivered to them by the MBI.

4. Write the MBI description. This is normally done in user story format but consider other formats if needed. (See Practice - Choosing a Requirement Format). Very large MBIs may be written using some of the extra elements found in the capability statement.

  • Define the minimum value based on what you know about the stakeholders to whom the MBI will be targeted.
  • If the scope of the MBI is not clear top-down, then do the following:
    • Create a list of features for a thorough implementation of a major value area from the capability.
    • Remove features until reaching a minimal list of features that you believe the stakeholder(s) will perceive as valuable.
    • Review your assumptions with the MBI stakeholder(s); ask them clarifying questions:
    • Is there a subset of this functionality that you would find useful?
    • If this package is not useful to you by itself, what could we add to it to make it useful?
  • Repeat steps a. and b. until the functional scope of the MBI has been defined.
  • Attach to the MBI any important supporting information that helped with defining the MBI.

5. Ensure that the MBI, as you are defining it, is implementable in an optimal way.

  • Communicate with more implementation-oriented roles, such as
    • Architect, the architect at the level of the system into which the capability will be implemented
    • Product owner, who represents the implementation teams
    • Technology owner
    • Technical leads
  • Edit the MBI to make it as implementable as possible, without adding implementation details. Concerns to evaluate include:
  • Implementable with available technologies.
  • Expandability
  • Modifiability
  • Optimal dependencies and coupling, and operability with systems around the MBI’s implementation.
  • Capture any bounds, limits, or constraints to be applied on the implementation such as performance, working within the other systems around the product.

6. Develop acceptance criteria for the MBI together with relevant stakeholders

7. Repeat steps 4 to 6 until the entire MBI and its parts satisfy all stakeholders as well as are practical to implement. 

Tools and Techniques

Tools and techniques that help with writing an MBI include a word processor, spreadsheet, or graphic tools to express the chosen requirement format and to model the information being used to create the MBI.


The objection is sometimes raised that “we don’t want to deliver the minimum; we want to deliver the maximum!” This ignores the fact that the time to develop functionality goes up exponentially with the amount being developed. That is, the more you do at once, the longer it takes to do every part of it and therefore the whole. This is due to many things, including more people to communicate with between the parts, less-frequent all-up integration, longer times to find problems and therefore to correct them, and so forth.

The challenge is not how to deliver more capability at the same time; no customer really cares about that. The challenge is how to deliver more capability over time. The key to delivering more is to do less at a time, but more often.


This practice yields MBIs that go back into the value stream / program backlog and specify.

  • The value of the MBI.
  • The bounds, limits and constraints to be levied on the implementation.
  • The least-possible amount of design and implementation direction; leaving those decisions to be made “just-in-time” at a later time.

When to Do This Practice

After a capability in the portfolio backlog has been approved for development based on the portfolio prioritization.


Following this practice will provide the best-possible foundation for development:

  • Identifying stakeholders and describing their needs that will be served.
  • Setting boundaries around the development effort, so it will achieve its goals without unnecessary gold-plating.
  • Leaving as much room as possible for implementation decisions to be made by the developers.