The Sprint and Sprint Planning

A heartbeat with no gaps in it

Sprints are fixed-length events of one month or less, and a new one starts immediately after the previous one concludes. There is no interval between them, no hardening period, no stabilisation week and no sign-off for anybody to wait on. A team that finishes its Retrospective on Friday afternoon and has booked Sprint Planning for the following Wednesday has not delayed the Sprint by two days — it has spent two days of the new Sprint with no Sprint Goal and no plan.

A team that believes it needs a hardening period is telling you something the exam sometimes asks about directly: its Definition of Done is too weak to make the Increment usable. The remedy is a stronger Definition of Done, not a gap in the cadence, and Scrum contains no such phase to schedule.

Each Sprint may be thought of as a short project, which is where the argument about length comes from. Shorter Sprints generate more learning cycles and confine the cost and effort at risk to a smaller window; as the horizon lengthens the Sprint Goal can go stale and complexity and risk both climb. Nothing in the framework is an argument for extending a Sprint that has already started — that trades away the predictability the fixed length exists to create, and it does it to protect a forecast rather than a goal. Unfinished items return to the Product Backlog and the Sprint ends on time.

Sprint Planning answers three questions in order

Why is this Sprint valuable, what can be Done this Sprint, and how will the chosen work get done. The Product Owner proposes how the product could increase in value, the whole Scrum Team collaborates on a Sprint Goal, and the Sprint Goal must be finalised before the event ends. It is the topic a busy team skips, and skipping it is expensive: without a Sprint Goal there is nothing protecting the Sprint from change, nothing for the Daily Scrum to inspect progress against, and nothing to commit to. A Sprint Planning that produced a list of work and no Sprint Goal produced a to-do list.

The second topic is a selection rather than an allocation: the Developers select items from the Product Backlog through discussion with the Product Owner, and the Developers are the ones who size them. The third topic is theirs alone — how the selected work becomes an Increment is at the sole discretion of the Developers, and decomposing items into pieces of a day or less is a technique Scrum mentions as common rather than a rule it imposes.

Three things that are not required, all of which appear as plausible options. There is no acceptance step where the Product Owner signs off estimates, because sizing is the Developers' responsibility and the Product Owner influences it by explaining trade-offs. There is no per-Sprint re-agreement of the Definition of Done, which is a standard for the product and is inspected in the Retrospective. And there is no requirement to decompose everything before Planning may end.

Timeboxes are ceilings, quoted for a one-month Sprint

Every published figure is a maximum and every one of them assumes a one-month Sprint: eight hours for Sprint Planning, four for the Sprint Review, three for the Sprint Retrospective. For shorter Sprints the events are usually shorter, and that is as precise as the framework gets. Scrum defines no proportional scale, so an option offering ninety minutes as the maximum Retrospective for a two-week Sprint is wrong however sensible halving the figure is in practice.

The Daily Scrum is the odd one out and it gives the pattern away: fifteen minutes, whatever the Sprint length, because it is a daily event rather than a per-Sprint one. The Sprint itself is the only one with a fixed length rather than a cap, which is what makes the cadence something an organisation can plan around.

A team that blocks the full eight hours because "eight hours is the rule" and reliably finishes in three has read a ceiling as a schedule. Finishing early with a Sprint Goal agreed is a successful Sprint Planning, not a truncated one. Keeping events inside their timebox is one of the ways a Scrum Master serves the team; filling them is not, and treating a timebox as a duration to consume is how a team learns to resent its own events.

What may change once the Sprint has started

Four things hold true throughout every Sprint. No changes are made that would endanger the Sprint Goal. Quality does not decrease. The Product Backlog is refined as needed. And scope may be clarified and renegotiated with the Product Owner as more is learned. Read together they describe a framework that protects exactly one thing and leaves everything else open, which is what lets a team learn during a Sprint without abandoning it.

Candidates lose marks by remembering only the first clause. Asked whether a Product Owner may push a small urgent unrelated item into the last two days of a Sprint, the answer is not "nothing may change during a Sprint" — the Sprint Backlog is updated throughout the Sprint as more is learned — it is that this particular change endangers the Sprint Goal, and the Sprint Goal is the thing a Sprint protects. Nor is there an equal-swap rule anywhere in Scrum: trading the new item for one of the same size can endanger the Sprint Goal exactly as easily as adding it can.

And the Product Owner does not need to override the protection, because they already have the one lever the framework gives them. If the Sprint Goal has genuinely become obsolete, they may cancel the Sprint. If it has not, the Goal is worth protecting for the fortnight it has left.