Planning Inputs and Preconditions

Planning Inputs and Preconditions are the artifacts, data, and organizational readiness factors that must be in place before an iteration planning session can produce a realistic, actionable plan. They represent the raw material and enabling conditions that planning transforms into a committed iteration scope; without them, a planning session tends to produce guesses rather than genuine commitments.

Categories of Inputs

The Product Backlog

The prioritized list of features, enhancements, and fixes maintained by the product owner. For planning to be effective, the top portion of the backlog must be sufficiently detailed and understood, since items still described only as vague ideas cannot be reliably estimated or committed to.

Definition of Ready

A shared checklist describing the minimum level of clarity a backlog item must reach before it can enter planning—typically including a clear description, acceptance criteria, and an understanding of dependencies. Items that do not meet this bar are considered unready and are excluded from the iteration's candidate scope.

Definition of Done

The agreed standard that determines when a piece of work is genuinely complete, covering aspects such as code review, testing, documentation, and deployment readiness. Planning without a shared definition of done leads to inconsistent judgments about whether committed work has actually been finished.

Team Capacity Data

Information about how many hours or story points the team can realistically deliver in the upcoming iteration, adjusted for holidays, planned leave, meetings, and other non-development obligations.

Historical Velocity

The team's throughput from recent iterations, used as an empirical anchor for how much work can be reasonably committed to, rather than relying on optimistic guesses.

Technical and Architectural Constraints

Known limitations, technical debt, or architectural decisions that affect how much work is feasible, which items depend on others, and where hidden complexity may reside.

Stakeholder Priorities and Constraints

Current business priorities, external deadlines, and any newly introduced requirements that may affect which backlog items should be pulled into the iteration.

Preconditions for an Effective Planning Session

A Refined and Prioritized Backlog

Backlog refinement should occur continuously before planning, so that by the time the session begins, top-priority items are already broken down, estimated, and clarified rather than being tackled for the first time during planning itself.

Availability of Key Participants

Planning requires the presence of those who can answer questions about priority, technical feasibility, and dependencies—typically the product owner, delivery team members, and any specialists needed to clarify complex items.

A Stable Team Composition

Significant, last-minute changes to team membership undermine capacity estimates and disrupt the shared context needed for effective planning, so a reasonably stable team is treated as a precondition for reliable commitments.

Resolved or Understood Dependencies

External dependencies that the iteration's work relies on should be identified and their status understood before planning, so the team is not committing to work that is blocked by factors outside its control.

A Clear Iteration Cadence

A consistent, known iteration length and schedule allows the team to plan against a fixed time box, rather than negotiating both scope and duration simultaneously, which tends to produce unstable commitments.

Assessing Input Readiness

Backlog Readiness Ratio

A low ratio signals that refinement work is incomplete and that planning is likely to stall on clarifying items rather than committing to them.

Effective Capacity

Consequences of Missing Preconditions

Underspecified Items Entering the Iteration

When items lack clear acceptance criteria, teams often discover mid-iteration that the work is larger or different than assumed, leading to scope surprises and schedule pressure.

Unrealistic Commitments

Planning without accurate capacity or velocity data tends to produce commitments based on optimism rather than evidence, setting the team up for a pattern of chronic under-delivery.

Repeated Blocking

Failing to identify unresolved dependencies before planning results in committed work becoming blocked shortly after the iteration begins, wasting the planning effort already invested.

Planning Session Overrun

When backlog refinement has not occurred beforehand, the planning session itself becomes consumed by clarification and estimation work that should have happened earlier, leaving insufficient time for genuine sequencing and commitment discussions.

Ensuring Preconditions Are Met

Continuous Backlog Refinement

Regular, smaller refinement sessions held throughout the iteration—rather than concentrated immediately before planning—keep the backlog consistently ready and reduce the burden on the planning session itself.

Capacity Tracking Discipline

Maintaining an up-to-date record of team availability, including known future absences, ensures capacity figures used in planning reflect reality rather than a generic assumption of full availability.

Dependency Visibility Tools

Shared dependency trackers or boards make the status of cross-team and external dependencies visible to the whole team, so planning can account for them explicitly rather than discovering them as surprises.