The key to decomposing an MBI into a Feature is understanding what a Feature is and how it differs from an MBI.

A Feature is a significant piece of functionality that is part of an MBI, is cohesive within itself (i.e., everything about it works together to do one thing), but will, if delivered by itself to a customer without the rest of the MBI, not be seen as enabling them to accomplish anything that they care about. Like all requirements, its specification must include acceptance criteria.

So, for instance, in the introduction to Decomposing a Capability into MBIs, we introduced the example of a basic swimming pool as an MBI. The MBI was defined by identifying the minimum set of features that, together, would fulfill the homeowner’s desire to have a basic swimming pool.

One of the features in a swimming pool MBI would likely be the capability to filter the water. During construction of the pool, someone would deliver a filtration system to the owner’s back yard to be integrated with the rest of the pool’s features.

A filtration system is a cohesive part of the overall pool. However, it does not, by itself, deliver anything the pool owner wants. The owner will probably not be pleased to take delivery only of the filtration system. He or she will either have to find a place to store it out of the weather, taking up room needed for other things, or leave it out in the yard, perhaps getting harmed by the weather, or perhaps getting covered with a tarp…in either case certainly being an eyesore.

What is a welcome and significant piece of functionality in the context of its MBI, becomes a liability if delivered by itself. This is the important difference between a Feature and an MBI.

The format of a Feature is the same as that of an MBI: It is a statement that usually takes the form of a User Story but sometimes is better captured in other formats (see Choosing Requirement Format).

Who does this practice

Features are created for Business values and Architectural functionalities.

• Business: Either Product Managers (PM’s) write Features with the assistance of Product Owners , or sometimes they delegate the writing of Features to the Product Owner.
• Architectural: Value stream or System Architects or ADMs typically write architectural Features. They will enlist support as needed from other architectural stakeholders (e.g., Technology Owners, Technical Leads).

What to do

Inputs

Inputs to this practice include:

• An MBI to be decomposed, drawn from the Value Stream backlog
• Consultation and supporting information from the capability owner(s), Product Mangers, and stakeholders

Approach

1. Choose the next MBI from the prioritized Value Stream Backlog
2. Obtain all written information about the MBI
   • If the MBI has been developed in accordance with the article Decomposing a Capability into MBIs, the MBI will include information about stakeholders as well as other supporting details.
   • If the capability has not been thoroughly defined, identify all stakeholders and develop channels of communication with them to allow communicating with them about the capability as you write it. See Decomposing a Capability into MBIs for ideas.
3. Review the information about the archetypal users (from the MBI’s supporting information) who will be the main focus of the Feature you will write. This includes both their wants (things they consciously know about already) and needs (what they may not consciously recognize yet).
4. Write the Feature. This is normally done in User Story format, but consider other formats if needed. See Choosing Requirement Format
   • Attach to the Feature any additional important supporting information you discovered while defining it
5. Ensure that the Feature, as you are defining it, is implementable in an optimal way.
   1. Communicate with implementation-oriented roles such as
      • Value stream Architect (the architect at the level of the system into which the capability will be implemented; this is one level below the Chief or Enterprise Architect)
      • The Product Owner (if not already working with the PM on this)
      • Application Development Manager or ADM
      • Technology Owner or TO
      • Technical Leads
   2. Edit the Feature to make it as implementable as possible, without adding implementation details. Concerns to evaluate include:
      • Implementable with available technologies
      • Expandability
      • Modifiability
      • Optimal dependencies and operability with systems around the Feature’s implementation
   3. Capture any bounds, limits or constraints to be levied on the implementation (e.g., performance)
6. Develop Acceptance Criteria for the Feature, in conjunction with stakeholders
7. Continue with steps 4 to 6 until the whole Feature and its parts satisfy all stakeholders as well as are practical to implement

Template: Features

The essential attributes of a feature are:

• ID. An identifier used to refer to the feature. Use an intention revealing name.
• Business Value. (optional / helpful) Indication of the value to the business. The Business decides on the scheme to use: a priority number, an estimate of ROI, an estimate of cost savings or risk reduction.
• Description. A few words to describe the feature. Here is a good template:
  • Who or what area, including the scope and scale (for example: all managers, only active customers)
  • The capability / functionality needed
  • When is it needed (urgency)
  • How we know we have achieved the value
  • The method or approach for validation
  • Acceptance tests and criteria to validate value realization
• Size. The size, in “points” of the feature. Must be able to be completed within the release.

Tools and techniques

Tools and techniques that help with writing a Feature include a word processor, spreadsheet, or graphic tools to express the chosen requirement format and to model the information being used to create the Feature (relationships with other Features in the MBI, or between subsystems that cooperate in executing the Feature, etc.).

Outputs

This practice yields a Feature that specifies

• The contribution toward the MBI value that the implementation of the Feature 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 an MBI has been placed into the value stream backlog, and approved for further development based on prioritization of the value stream backlog

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