A capability is composed of one or more MBIs. The first key is to understand what an MBI is. Decomposition commences with identifying the potential 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 “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.

The MBI is in effect the indivisible “atom” of business value.

An example of this is a “swimming pool MBI.” You can list all the conceivable features of a swimming pool such as a filter system, a 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, have an impressive list. Do all of them have to be delivered in one big package though?

If the homeowner has any limitations to his or her budget, or if they would like to start using the pool sooner than an all-up, bells-and-whistles pool could be built and opened. The question becomes, what is the smallest set of features that would satisfy the homeowner as 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 their project (even if that money is just the down payment on the loan), they get to start using the pool sooner (another acceleration of value), and they might even be able to pay for the rest of the pool with future upgrades while enjoying their basic pool.

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 they have the pool built, is unlikely to make them happy. Indeed, accepting it means now they must try to find a place to store it. Extra work, no new benefit. An irritant. Like when your favorite software tool is updated, rearranging menues and adding options you don’t want. Making it harder to use what you already were happy with.
• 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 jumping down one more level of detail and thinking about potential features that might go into the MBI.
• 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 what they want, as soon as possible.
• MBIs are all about boundaries…what is absolutely needed to make the MBI into something the customer will recognize as value? What can we make not go into the MBI, 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: Value stream or System Architects, or ADMs, 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

Inputs to this practice include:

• A capability statement in a Portfolio Backlog, approved for further development.
• Consultation and supporting information from the Project Managers, Product Owners, and stakeholders such as customers, customers’ customers (generally coordinated with the first-line customer’s agreement), users, and regulators.

Approach

1. Choose the next capability statement in the portfolio backlog based on backlog prioritization.
2. Obtain all written and verb al information about the capability to be decomposed into an MBI.
   • If the capability has been developed in accordance with Writing a Capability, it will include information about stakeholders as well as other supporting details.
   • If the capability has not been thoroughly defined, identify all major stakeholders and develop channels of communication with them to allow communicating with them as you write MBI requirements.
3. Develop a deeper understanding of the archetypal stakeholders of the capability who will be the focus of the first MBI you will write. 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 as described in Writing a Capability.
   • 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
4. 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.
5. Write the MBI. This is normally done in User Story format, but consider other formats if needed. See Choosing a Requirement Format. Very large MBIs may be written using some of the extra elements found in the Capability Statement.
   1. Define the minimum value based on what you know about the stakeholders to whom the MBI will be targeted
   2. 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 value.
      • Validate your assumptions about the MBI stakeholder(s) by asking them if they would view a package of this list of features as useful to them. 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 1 and 2 until the functional scope of the MBI has been defined.
   3. Attach to the MBI any important supporting information that helped with defining the MBI.
6. 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, or the Application Development Manager or ADM; this is one level below the Chief or Enterprise Architect)
     • The Product Owner (PO, who represents the implementation teams)
     • Technology Owner or TO
     • 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 (e.g., performance; working within the other systems around the product).
7. Develop Acceptance Criteria for the MBI in conjunction with relevant stakeholders
8. Repeat steps 5 to 7 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 (relationships, etc.).

Discussion

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 capabilityover time. The key to delivering more is to do less at a time, but more often.

Outputs

This practice yields MBIs that go back into the value stream (e.g., program) backlog, and specify

• The value the implementation of the MBI must deliver
• 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” later

When to do this practice

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

Where to do this practice

This practice is not specific to any location.

Outcomes

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