Selected Work Clarification

Selected Work Clarification is the step within iteration planning where items already pulled into the iteration are examined in enough depth to remove ambiguity about what each one actually requires, ensuring the team begins execution with a shared, precise understanding rather than a superficial agreement based on the item's title alone. It occurs after selection but before task breakdown, closing the gap between "we agreed to do this" and "we understand exactly what doing this involves."

Why Clarification Is Necessary Even After Selection

Selection Confirms Priority, Not Understanding

An item can be correctly selected based on its priority and estimated size while the team still holds subtly different interpretations of what it actually entails. Clarification exists specifically to surface and resolve these differences before they cause conflict during execution.

Definition of Ready Sets a Floor, Not a Ceiling

Even items that technically meet the definition of ready may still contain edge cases, implicit assumptions, or unresolved design questions that only become apparent once the team discusses the item in detail immediately before starting work.

Preventing Divergent Interpretations Across Team Members

Without explicit clarification, different individuals working on related aspects of the same item may proceed on inconsistent assumptions, leading to integration problems discovered only when their work is combined.

What Clarification Covers

Precise Scope Boundaries

Establishing exactly what is included and, just as importantly, what is explicitly excluded from the item, preventing both underdelivery and unplanned scope expansion during execution.

Acceptance Criteria Confirmation

Reconfirming the specific, testable conditions that must be true for the item to be considered complete, ensuring there is no ambiguity about what "done" means for this particular piece of work.

Edge Cases and Exceptional Conditions

Discussing unusual inputs, failure scenarios, or boundary conditions that the implementation must handle, which are often glossed over in the item's original high-level description.

Interaction With Existing System Behavior

Clarifying how the new work is expected to interact with existing functionality, particularly where the change could have subtle side effects on unrelated parts of the system.

Design and Technical Approach Alignment

Where multiple viable technical approaches exist, the team aligns on which approach will be used, preventing later disagreement or duplicated exploratory effort.

Methods for Achieving Clarification

Structured Walkthroughs

The team reads through the item together, question by question, rather than assuming silent agreement, actively inviting objections and alternative interpretations before proceeding.

Example-Based Discussion

Working through concrete examples of expected input and output, or specific user scenarios, often reveals ambiguities that abstract descriptions of the requirement fail to surface.

Whiteboarding or Diagramming Complex Flows

For items involving multiple system interactions, sketching the flow visually helps the team spot gaps or inconsistencies that are difficult to detect from text descriptions alone.

Direct Engagement With the Product Owner

When ambiguity concerns business intent rather than technical detail, the product owner is consulted directly during the clarification step, rather than the team guessing at the intended behavior.

Outcomes of Effective Clarification

Reduced Mid-Execution Rework

Ambiguities resolved before work begins prevent the costly cycle of building something, discovering it does not match actual intent, and rebuilding it partway through the iteration.

Faster, More Confident Task Breakdown

Once an item is genuinely clear, breaking it into concrete technical tasks becomes significantly faster, since the team is no longer simultaneously trying to understand the requirement and decompose it.

Consistent Understanding Across Contributors

When multiple people will work on related parts of an item, shared clarification ensures their individual contributions integrate smoothly rather than reflecting divergent assumptions.

Measuring Clarification Quality

Mid-Iteration Clarification Requests

A persistently high rate suggests that the clarification step during planning is being rushed or skipped, pushing the cost of ambiguity resolution later into the iteration, where it is more expensive to address.

Common Failure Modes

Assuming Clarity From Familiarity

Skipping clarification for items that resemble previously completed work, without checking whether this specific instance carries different nuances, can introduce subtle but consequential misunderstandings.

Rushing to Preserve Meeting Time

Cutting clarification short to keep the planning session within its timebox often shifts the cost of unresolved ambiguity into the iteration itself, where it is harder and more disruptive to resolve.

One-Sided Clarification

Allowing a single team member to clarify an item on behalf of everyone, without genuine group discussion, risks propagating one person's incomplete or incorrect interpretation to the rest of the team.

Confusing Clarification With Re-Litigating Priority

Using the clarification step to reopen debate about whether the item should have been selected at all, rather than focusing on understanding its scope, derails the purpose of the step and consumes time better spent elsewhere.