This reading path introduces concepts involved in decomposing requirements in Lean-Agile.

The reason we write software is to create value for our organizations and customers. Yet, our vision of that value almost always starts out blurred and inaccurate.

Requirements are traditionally the way we define the value to be mapped into products. For many years, requirements have been placed all together in a durable repository like a BRD (Business Requirements Document). The organization hopes that the requirements will remain close enough to our evolving understanding of the need for which we’ve written them, so that we won’t need to change them much.

The reality is that, for most products, our understanding of value changes significantly throughout development. If the requirements specify too much detail at the beginning, or tie the hands of the developers too tightly, the requirements themselves will have to be changed to match the natural unfolding of understanding. This leads to expensive rework and even redesign.

The Lean strategy for managing this challenge is “Just-In-Time” (JIT) requirements. We begin by describing the desired value to be served by the product, at a high and abstract level. This is the level we are the most likely to understand at the very beginning of implementing the value. It is called the level of the “Capability.”

As we move further along toward a product, we add detail, layer by layer, to our description of what is needed. We always add “just enough” detail to keep the work progressing, but never more than what we need at the time.

In this way, as we gain new understanding that would have required us to change “all-in” up-front requirements, now we simply add new levels of detail. The amount of backtracking and change to undo overly early decisions is drastically reduced.

Just-In-Time requirements are created in increasingly-detailed levels:

• Capability: A top-level description of new or improved value and/or function that the Business will be able to provide. Capabilities flow out of strategies, are often supported or augmented by software, and are often managed in a Lean portfolio.
• Minimum Business Increment (MBI): The indivisible “atom” of business value to be realized by a customer
• Feature: Significant functionality toward implementing the value in an MBI, but not stand-alone
• Story: Functionality that is part of a feature and is sized such that that a reasonably small team of 10-12 people
• Tasks: An implementer-oriented description of work to be done to create an aspect of the system delivering value

Important caveat: Systems thinking says that “The whole is greater than the sum of the parts.” Simply decomposing a capability into all its constituent team stories (and indirectly, tasks) does not fully define what the whole product will do when it is assembled. In the same way that no individual part of an airplane is responsible for its overall capability for flight, so also the pieces of a software product do not fully define how the product will work as a whole. This is both positive, such as when new capabilities that come from combining the individual parts that were built, and negative, such as when there are conflicts between the parts of a system that performance problems, interferences, etc).

At all times when decomposing requirements into smaller pieces, keep the holistic view of the system in mind.