Lesson 34: Sprint Planning & Backlog Grooming

Lessons 32 and 33 gave you the two dominant Agile frameworks at the level of their overall philosophy and structure — Scrum's roles, events, and artifacts, and Kanban's flow-based alternative. But knowing that "Sprint Planning" exists as an event, and knowing how to actually run one well, are very different levels of fluency. This lesson goes underneath the event itself, into the specific mechanics that separate a Sprint Planning meeting that produces a coherent, achievable Sprint Backlog from one that produces an overcommitted wish list nobody actually believes in.

This lesson also directly resolves two loose threads left open earlier in this module. Lesson 31's Detailed Case Study ended with a PM forcing a sprint plan through after learning it rested on a false assumption, specifically because there was no established process for handling mid-sprint changes gracefully — this lesson builds that process. And Lesson 32's Case Study identified an unclear Definition of Done as a recurring, unresolved retrospective complaint — this lesson gives you the specific tool (a Definition of Ready, paired with the Definition of Done) that prevents that ambiguity from reaching the sprint in the first place. Backlog grooming is where a PM's upstream prioritization work (Lesson 29) gets translated into units small and clear enough for engineering to actually commit to — and doing this translation poorly is one of the most common, and most avoidable, sources of execution dysfunction in product organizations.

Learning Objectives

1
Explain the difference between backlog grooming (an ongoing, continuous activity) and Sprint Planning (a discrete event), and why conflating the two produces rushed, poor-quality sprints.
2
Apply the INVEST criteria to evaluate whether a backlog item is well-formed enough to bring into Sprint Planning.
3
Define a Definition of Ready and explain how it complements, without duplicating, the Definition of Done from Lesson 32.
4
Explain capacity-based sprint planning using velocity, and identify the most common estimation pitfalls that lead to systematic overcommitment.
5
Design a mid-sprint change protocol that allows a team to respond to significant new evidence without either destabilizing the Sprint Goal or defaulting to rigid over-commitment, directly resolving the failure mode from Lesson 31's Case Study.

This lesson assumes Lesson 29's prioritization logic — you should already know how to rank a raw list of candidate ideas by value and cost. It also assumes Lesson 32's Scrum vocabulary in full: Sprint Backlog, Sprint Goal, and especially the Definition of Done, since this lesson introduces a companion concept (the Definition of Ready) that only makes sense in contrast to it. Finally, it assumes you remember Lesson 33's Kanban concepts of WIP limits and cycle time, because well-run backlog grooming is, in effect, a continuous-flow discipline (grooming happens constantly, not just at Sprint Planning) applied to a Scrum team's otherwise batch-oriented process.

Grooming Is Continuous; Planning Is a Single Event

The single most common structural mistake in this space is treating backlog grooming and Sprint Planning as the same activity, performed only once every Sprint. They are not. Backlog grooming (also called backlog refinement) is an ongoing activity — ideally happening in small doses throughout the Sprint, not concentrated into a single pre-planning session — where the PM and team progressively clarify, split, and estimate upcoming backlog items well before they're due to enter a Sprint. Sprint Planning is the discrete Scrum event (Lesson 32) where the team selects already-groomed items into the Sprint Backlog and forms a Sprint Goal.

When grooming is skipped and pushed entirely into the Sprint Planning meeting itself, the team is forced to clarify scope, split oversized items, and estimate effort all in the same session where it's also supposed to be forming a coherent Sprint Goal — a workload mismatch that reliably produces either a rushed, shallow planning session or one that runs for hours. Continuous grooming exists specifically to prevent this collision.

The INVEST Criteria

A widely used mnemonic, commonly attributed to Bill Wake, for evaluating whether a backlog item (often written as a user story) is well-formed enough to enter Sprint Planning:

Letter	Criterion	What It Checks
I	Independent	Can this item be built and delivered without being blocked on another unfinished item?
N	Negotiable	Is the item a statement of a problem/need, not an over-specified technical solution the team has no room to shape?
V	Valuable	Does the item clearly connect to a real user or business outcome, not just an internal technical task with no visible value?
E	Estimable	Does the team have enough information to give a reasonable size estimate?
S	Small	Is the item sized to be completed comfortably within a single Sprint, ideally a fraction of it?
T	Testable	Is there a clear, verifiable way to know when the item is actually done?

An item failing "Estimable" or "Small" is the most common real-world grooming failure — a large, vague item ("improve onboarding") gets dragged into Sprint Planning, is nominally "estimated," and then blows through its estimate because no one actually broke it down into pieces small enough to reason about clearly.

Definition of Ready, Paired With Definition of Done

Lesson 32 introduced the Definition of Done: a shared standard every Increment must meet before being considered complete. This lesson introduces its natural complement, the Definition of Ready: a shared standard a backlog item must meet before it is allowed to enter Sprint Planning at all. A typical Definition of Ready might require that an item has a clear acceptance criteria, has been estimated, has no unresolved external dependencies, and has been reviewed by both a PM and an engineer.

The pairing matters because each standard guards a different transition:

A team with a strong Definition of Done but no Definition of Ready will frequently pull poorly-specified, oversized items into a Sprint, then discover mid-Sprint that the item was never actually well-formed enough to build — precisely the ambiguity that produced the recurring, unresolved complaint in Lesson 32's Case Study. Establishing a genuine Definition of Ready is the direct fix for that dysfunction.

Capacity-Based Planning and Velocity

Most Scrum teams plan a Sprint's capacity using velocity — a rolling average of how many story points (or equivalent estimation units) the team has completed in recent past Sprints. Rather than optimistically committing to however much backlog looks appealing, a disciplined team commits only up to its established velocity, adjusted for known factors like planned time off or a public holiday shortening the Sprint.

A simple, commonly used formula: Sprint Capacity ≈ Historical Velocity × Focus Factor, where the Focus Factor (often somewhere between 0.7 and 0.85 for many teams) accounts for the reality that not all of a team's nominal time converts into feature-delivery work — meetings, support interruptions, and unplanned work all consume real capacity that a naive full-time-hours estimate ignores.

The most common estimation pitfall is planning fallacy: systematically underestimating how long work will take, driven by focusing on the best-case scenario for a specific task while ignoring the base rate of how long similar tasks have taken historically. Anchoring Sprint commitments to actual historical velocity, rather than to each Sprint's fresh, optimistic estimate, is the primary structural defense against this bias.

Common Mistakes to Avoid

Grooming the entire backlog inside the Sprint Planning meeting itself

As covered above, this collapses two workloads (clarifying/splitting/estimating, and forming a coherent Sprint Goal) into one meeting, reliably producing either a rushed session or one that runs far longer than intended.

Writing backlog items as technical solutions instead of problems or needs

An item like "add a Redis cache layer to the search endpoint" violates INVEST's "Negotiable" criterion — it pre-supposes the solution and removes the team's ability to propose a better one. A better-formed version states the underlying need ("search response time is causing measurable user drop-off") and lets engineering propose the technical approach, including a cache layer if that's genuinely the best fix.

Committing to Sprint capacity based on optimism rather than historical velocity

Teams new to Scrum frequently plan each Sprint as if it will be the team's best Sprint ever, ignoring their own established velocity trend. This produces chronic overcommitment, and — worse — chronic overcommitment quietly erodes a team's trust in the Sprint Goal itself, since it becomes an expectation everyone privately assumes won't be met.

Having a Definition of Done but no Definition of Ready

As covered above, this allows poorly-specified items to enter a Sprint, where their ambiguity surfaces as a mid-Sprint surprise rather than being caught during grooming, when it's far cheaper to resolve.

Treating any mid-sprint change as either forbidden or trivial, with no middle-ground protocol

This is the exact failure from Lesson 31's Case Study: a PM who treats the sprint plan as untouchable regardless of new evidence. The opposite failure also exists and is just as damaging — a team that re-plans the Sprint casually every time something new comes up, never actually protecting a period of focus. The fix, covered next, is a deliberate middle path.

Mental Model

The Readiness Gate

This lesson's core takeaway tool visualizes backlog grooming as a gate that filters raw ideas down to Sprint-ready items, using INVEST and the Definition of Ready together as the gate's actual criteria rather than a rubber stamp:

Use the Readiness Gate as a standing discipline in every grooming session: an item that can't pass through it honestly is not ready, regardless of how much pressure exists to bring it into the next Sprint anyway. The gate's real value is forcing the "Split into smaller items" step to happen during grooming — a calm, unhurried setting — rather than being discovered mid-Sprint, under time pressure, as an unpleasant surprise.

Quick Reflection Checkpoint

Key Takeaway: How will you apply "The Readiness Gate" when evaluating trade-offs in your product decisions?

Sprint Planning & Backlog Grooming