Dependency and Constraint Review

Dependency and Constraint Review is the systematic examination, conducted during iteration planning, of the external dependencies and limiting constraints that could affect the team's ability to complete the selected work, so that these factors are identified and accounted for before commitment rather than discovered mid-iteration as unexpected blockers. It treats visibility into what could impede progress as a prerequisite for a trustworthy plan, rather than something to be handled reactively as problems arise.

Distinguishing Dependencies From Constraints

Dependencies as Relational Blockers

A dependency exists when the completion of one piece of work relies on something outside the team's direct control—another team's deliverable, a third-party service, a shared library, or a decision from another part of the organization.

Constraints as Boundary Conditions

A constraint is a limiting factor that shapes how work can be done without necessarily involving another party—such as a fixed regulatory deadline, a required technology standard, a security policy, or a hard limit on available infrastructure.

Why Both Require Explicit Review

Dependencies and constraints frequently share a common danger: they are often invisible in a simple backlog item description and only become apparent when someone deliberately asks what could stand in the way of completing the work as planned.

Categories Commonly Reviewed

Cross-Team Dependencies

Work that requires deliverables, approvals, or coordination from teams outside the immediate delivery team, where delays are outside the team's direct authority to resolve.

Third-Party and Vendor Dependencies

Reliance on external services, APIs, libraries, or vendor-provided components whose availability, stability, or delivery timeline the team does not control.

Technical Constraints

Existing architecture, legacy system behavior, or infrastructure limitations that restrict which technical approaches are viable for the selected work.

Resource Constraints

Limits on specialized skills, licenses, environments, or tools required to complete certain items, which may be scarce or shared across multiple teams.

Regulatory and Compliance Constraints

Legal or policy requirements that dictate specific behavior, documentation, or approval processes the work must satisfy before it can be considered complete.

Environmental and Scheduling Constraints

Fixed external dates, such as scheduled maintenance windows, freeze periods, or coordinated release dates, that limit when certain work can be safely performed or deployed.

The Review Process

Item-by-Item Dependency Identification

For each selected backlog item, the team explicitly asks whether its completion relies on anything outside the team's control, rather than assuming the absence of dependencies by default.

Constraint Mapping Against Selected Work

The team cross-references known organizational, technical, and regulatory constraints against the selected items to identify where any of them apply.

Status Verification

For each identified dependency, the team checks its current status—confirmed, in progress, or unconfirmed—rather than assuming a dependency will resolve favorably without verification.

Risk Assessment for Unresolved Dependencies

Dependencies that remain unconfirmed are assessed for their likelihood of resolving in time and the impact if they do not, informing whether the associated work should proceed as planned, be deprioritized, or be held back.

Mitigation Planning

For significant risks identified, the team considers mitigation options, such as beginning with the parts of an item that do not require the dependency, or identifying a fallback approach if the dependency fails to resolve.

Consequences of Skipping Review

Blocked Work Mid-Iteration

Items that appeared straightforward during selection can become stalled when an unidentified dependency fails to resolve, wasting the capacity allocated to that item and disrupting the overall iteration plan.

Erosion of Commitment Reliability

Repeated dependency-driven failures to complete committed work damage stakeholder trust in the team's planning process, even when the underlying cause was outside the team's control.

Missed Regulatory or Policy Obligations

Failing to account for compliance constraints during planning can result in delivered work that must be reworked or withdrawn after the fact, at significantly higher cost than addressing the constraint upfront.

Quantifying Dependency Risk

Dependency Exposure

A high exposure ratio signals that a substantial portion of the iteration's success depends on factors outside the team's control, warranting closer monitoring or contingency planning.

Common Failure Modes

Assuming Dependencies Will Simply Resolve

Proceeding with planning under an optimistic assumption that an unconfirmed dependency will be delivered on time, without any contingency, leaves the team exposed to avoidable disruption.

Reviewing Dependencies Only for New Work

Overlooking dependencies affecting carried-over or in-progress items from the previous iteration can allow known risks to persist unaddressed across multiple planning cycles.

Treating the Review as a One-Time Checklist

Conducting dependency review only at the start of the iteration, without revisiting it as circumstances change, misses the opportunity to catch newly emerging risks before they cause disruption.

Failing to Communicate Identified Risks to Stakeholders

Identifying a significant dependency risk internally but not surfacing it to stakeholders who could help resolve or mitigate it wastes an opportunity for early intervention.