Successively more-detailed layers
Requirements are developed “Just-In-Time,” in successively more-detailed layers.
| Layer |
Description |
| Capability |
Definition: A capability is a formal, high-level description of a quality or ability that has been proposed at higher levels and then approved for development based on the expectation that it will help the organization meet major goals.
In Lean-Agile, there are two kinds of capabilities:
- Business Capability. A description of a quality or ability that the Business requires in order to meet its goals. Usually, Business Capabilities flow from strategic concepts of the organization.
- Architectural Capability. A description of large technology initiative that addresses issues such as technology integration, obsolescence, scalability, performance, or taking advantage of new technologies or standards. Architectural Capabilities often cut across a portfolio.
Scope: The development work to implement a capability occurs in from one to many business units. Capabilities flow out of strategies, are often supported or augmented by software, and are often managed in a Lean portfolio. These capabilities map loosely to capability statements called out as business solutions in project charters or statements of work.
Author: For Business Capabilities, the primary author is a Product Manager. For Architectural Capabilities, the primary author may be the senior architect (e.g., Chief or Enterprise) who originated the concept. |
| MBIs |
Definition: The smallest grouping of capability that is worth delivering to a customer so that they can realize value from the work. The indivisible “atom” of business value. Delivering anything less than this package of capability will not be perceived by the customer as providing them with what they want or need. Indeed, they may even be irritated by receiving new functionality that they must think about, but which does not enable them to do anything more that they care about or use the system to accomplish.
Scope: The work to implement an MBI is usually performed within a single business unit. Within the business unit, though, it can cross multiple teams and Macro Iterations.
Author: Product Manager, sometimes with support from Product Owner.
Optional: The writing of the MBI may be driven by a written “vision” for what it will accomplish. |
| Features |
Definition: Significant functionality toward implementing the value in an MBI, but not recognized by the customer as standalone value by itself.
Scope: The work is (usually) doable within a single Macro Iteration within a single value stream or program, and ideally fits within a single release within a Macro Iteration. Its implementation may still require work by multiple teams.
Author: Product Manager and Product Owner, ideally working together. |
| Stories |
There can be two levels of stories.
- Team-level stories (the higher level)
- Definition: This level comes from decomposing a Feature into stories.
- Scope: Each team-level story can be implemented by a single team. It may take more than one iteration to complete.
- Author: Product Owner, with support from the team.
- Right-sized stories (the level below Team-level stories)
- Definition: Right-sized stories are decomposed from Team- level stories.
- Scope: They can be developed in 2-3 days in a single iteration by one team.
- Author: Product Owner, with heavier support from the team.
|
| Tasks |
Definition: From Feature to Story, the requirement is written when possible from the perspective of the customer or other recipient of value. A Task, however, is from the perspective of those doing the work.
Each Team member creates tasks unique to their role: developer tasks, testing tasks, impediment resolution tasks, etc. A task can also be used to suggest that exploratory testing be performed. A task can be used generically to assign work within the project.
Scope: Typically, Tasks are sized to be implemented within a single iteration and by a single team.
Author: Usually written by team members rather than the Product Owner. |
Make them customer-centric
With the exception of Tasks, try to write requirements from the view of the customer (ow whomever is receiving the value) rather than from a traditional system-centric viewpoint. The User Story format is ideal for this. Use language like, “As a <kind of user>, I want to…” (customer-centric) rather than “The system shall…” (system-centric).
Acceptance criteria
A requirement is only complete when it also contains acceptance criteria by which its implementation will be judged as complete and satisfactory
- Working through acceptance criteria with the recipient of the requirement’s value (e.g., the customer) will help with understanding their needs and expectations. That leads to writing better requirements
- Thus, best practice is to develop acceptance criteria along with the requirement, completing them at the same time that the requirement story part is completed (both may of course change later)
- The latest that Capability, MBIs and Features can have their initial acceptance criteria fully defined is by the Macro Iteration Planning Event. This, however, loses the opportunity to use them to improve the stories
Four levels of repositories
Requirements progress through four levels of repositories as they are decomposed and increasingly detailed. Backlogs are not commitments, but rather are pools from which to draw. Thus, any backlog is subject to being prioritized, having some backlog items approved for further work, and others rejected from proceeding further.
Here are the levels of repositories.
| Level |
Description |
| Enterprise Portfolio |
The Enterprise Portfolio holds relatively-informal descriptions of concepts for strategic Business and Architectural capabilities, which are claimed they would have direct, significant organizational ROI impacts. These have not yet been approved for development.
- These concepts are captured by informally describing capabilities that deliver value. They may include supporting information, but they do not in general use a formal requirement format.
- This level of repository may be omitted in smaller organizations, or supplemented by additional layers of enterprise repositories and backlogs in very large organizations.
|
| Portfolio Backlog |
The Portfolio backlog holds capabilities, either
- Developed after approval of strategic concepts by enterprise management, from the enterprise capability concepts maintained in the Enterprise Portfolio, or
- Initiated at the portfolio level; of lesser scope than those derived from the Enterprise Portfolio.
Capabilities flow out of strategies, are often supported or augmented by software, and are often managed in a Lean portfolio. |
| Value Stream Backlog |
The Value Stream Backlog holds
- Minimum Business Increments (MBIs): Decomposed from Capabilities
- Features: decomposed from MBIs. All MBIs should be fully decomposed into Features
A Value Stream Backlog resides within a single business unit. MBIs can cross multiple teams and/or Macro Iterations. Features are targeted to a scope of no larger than a single Macro Iteration, and ideally, to a single release within the Macro Iteration.
This is sometimes called the “Program Backlog” in organizations that develop in batch instead of in continuous flow of value. |
| Team Backlog |
The Team Backlog holds Stories decomposed from Features in the Value Stream Backlog, Tasks, and work identified by the team itself (retiring technical debt, doing research), and other sources (“shoulder-taps” from management—not recommended, but must be integrated with other work when it happens—prior commitments, and so forth).
A team backlog applies to a single team, and is used to manage their individual iterations. |
|
