Requirements are traditionally the way we define the value to be mapped into products. 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 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.

Resources related to requirements

Acceptance Test-Driven Development (Article)
Capability (Article)
Choosing Requirement Format (Article)
Decomposing Requirements (Article)
Decomposing a Capability Into MBIs (Article)
Decomposing a Feature Into Stories (Article)
Decomposing an MBI into Features (Article)
Do We Have So Much Technical Debt That We Need to Pay Some Down Before Proceeding? (Article)
Do We Push, Plan or Pull Our Work? (Article)
Go for Understandable, Not Simple (Article)
How Do We Align People / Teams to the Work To Be Done? (Article)
How Does Agile at Scale Increase the Delivery of Business Value? (Blog Entry)
How Is Work Within the Program Being Sequenced? (Article)
How Should We Manage the Number of Items in the Portfolio? (Article)
How Should Work at the Portfolio Level Be Sequenced? (Article)
How Small Are Our Stories? (Article)
How Will Architectural Capabilities Be Handled? How Will Architecture Be Prioritize Against Business Needs? (Article)
How Will UX Work With the Teams? (Article)
How Will We Express, Decompose and Validate Requirements? (Article)
How Will We Make the Work at the Portfolio Level Visible? (Article)
If We Do Estimate, What Estimation Method Should We Use? (Article)
Product Owner Library (Article)
Product Planning and Review - Conduct (Article)
Test-Driven Development: ATDD and UTDD (Article)
The Need to Improve Clarity of a Requirement (Article)
The Net Objectives Program Board Builder (Article)
The Role of the Business Analyst in an Agile World (Article)
What Design Method Will Be Used? (Article)
What Should the Planning Cycle Be? (Article)
Writing Tasks (Article)
Writing a Capability (Article)