Sprint Planning
A time-boxed Scrum event where the team collaborates to define what work will be delivered in the upcoming sprint and how that work will be accomplished.
What it is
Sprint Planning kicks off every sprint and is time-boxed to a maximum of two hours per week of sprint duration. The entire Scrum Team participates. The event answers two questions: what can be delivered, and how will the work be done? The Product Owner proposes the highest-priority Product Backlog items. The Developers examine capacity, past velocity, and complexity to determine what is realistic. During the second part, Developers break down selected items into tasks for the Sprint Backlog.
When to use it
- At the start of every sprint
- When stakeholder visibility is required
- When working within funded programme increments
- When the team needs shared commitment and clarity
Key concepts
Sprint Goal
A short, shared objective that gives the sprint coherence. It explains why the sprint is valuable and helps the team make trade-off decisions during the sprint.
Capacity Planning
Accounting for leave, holidays, other commitments, and non-sprint obligations. In New Zealand this includes public holidays, regional anniversary days, and seasonal leave patterns.
Task Breakdown
Decomposing stories into actionable tasks. Tasks should be small enough to complete within a day and clearly owned by the Developers doing the work.
Commitment vs Forecast
The team commits to the Sprint Goal, not every task. The Sprint Backlog is a forecast of the work needed to meet that goal, and it can change as the team learns more during the sprint.
Common pitfalls
- Treating it as a status meeting
- Setting a Sprint Goal that is just a list of stories
- Overcommitting based on pressure
- Ignoring team capacity
- Skipping task breakdown
NZ context
In NZ government digital projects, Sprint Planning often aligns with broader programme governance and assurance milestones. Clear Sprint Goals are especially important for demonstrating incremental value to stakeholders.
Industry Reality
- Most teams run Sprint Planning well under the time-box — a two-week sprint rarely needs four hours; experienced teams often wrap in 60–90 minutes by doing backlog refinement continuously rather than front-loading everything into planning.
- The Sprint Goal is frequently a fiction. Teams write one because the framework requires it, but in practice it is often "finish the stories from last sprint plus these three new ones" — senior practitioners push back on this and insist on a real objective, even an imperfect one.
- Capacity planning is almost always optimistic. Unplanned support tickets, impromptu stakeholder calls, and public holidays (especially in NZ where regional anniversary days catch teams off guard) erode velocity more than teams forecast at the start.
- Story point estimates drift in meaning over time. Teams that skip calibration sessions end up with wildly inconsistent sizing, so many experienced teams switch to rough t-shirt sizing or #NoEstimates approaches and rely on throughput data instead.
- In NZ government and large enterprise settings, Sprint Planning often has an unofficial "pre-planning" meeting the day before where the Product Owner and tech lead align on priority — the formal ceremony then moves faster because the hard conversations already happened.
Context guide
How the right level of Sprint Planning effort changes based on team context.
| Context | Priority | Why |
|---|---|---|
| NZ government programme with quarterly funding gates (e.g. Benefits NZ digital services, TransitNZ capital works) | Essential | Sprint Goals must map to programme increment objectives to satisfy governance. Clear capacity planning prevents over-commitment during public holiday-heavy quarters (e.g. Waitangi Day through Easter). |
| Cross-functional product team with stable backlog (e.g. Pacific Bank mobile banking, TeleNZ consumer platform) | Essential | Cadenced delivery with multiple squads means Sprint Goals must be coherent across team boundaries. Poor planning causes downstream dependency failures and integration pain at sprint end. |
| Regulated environment with compliance gates (e.g. HealthNZ HealthNZ, KiwiSaver administrator) | High | Regulatory sign-off timelines (e.g. Privacy Act 2020 PIAs, NZISM security controls) must be factored into sprint capacity. Slipping compliance tasks to future sprints creates audit risk and release delays. |
| Small startup or agency team delivering client projects (under 5 people) | Medium | Sprint Planning overhead can exceed its coordination benefit at this scale. A lighter 30-minute weekly prioritisation meeting often works better; retain the Sprint Goal concept but skip full task breakdown. |
| Continuous-flow support team handling unplanned incidents (e.g. Revenue NZ contact centre tooling, CoverNZ claims platform on-call) | Low | Work arrives unpredictably and cannot be forecast two weeks ahead. Kanban replenishment and a service-level expectation model is more appropriate; Sprint Planning creates false commitments the team cannot honour. |
| Discovery or alpha phase with high uncertainty (e.g. new Pacific Air customer product, LandNZ data platform prototype) | Low | Story sizing is meaningless when the solution space is unknown. Short experiment loops with weekly review better serve discovery phases; introduce Sprint Planning once the team moves into delivery mode. |
Trade-offs
What you gain and what you give up when you adopt Sprint Planning.
| Advantage | Disadvantage | Use instead when… |
|---|---|---|
| Shared commitment — the whole team, including testers, understands what is being built and why. No one is surprised mid-sprint by scope they were not part of committing to. | Ceremony cost — even a well-run Sprint Planning takes 60–90 minutes per fortnight. For a five-person team that is a meaningful fraction of delivery capacity if the backlog is poorly prepared. | Work arrives unpredictably (support queues, incident response) and cannot be forecast two weeks ahead — use Kanban replenishment instead. |
| Explicit capacity accounting — leave, public holidays (including NZ regional anniversary days), and BAU obligations are surfaced and protected, reducing mid-sprint surprises. | False precision risk — velocity and story points can create an illusion of accuracy. Teams sometimes commit to a number that feels scientific but is really a guess dressed in jargon. | The team is in pure discovery mode and story sizing is meaningless — run short weekly experiment loops until the solution space is understood. |
| Sprint Goal as a decision tool — when a mid-sprint blocker forces a trade-off, the Sprint Goal tells the team what to protect and what to drop without needing an emergency Product Owner meeting. | Backlog dependency — Sprint Planning is only as good as the backlog behind it. Unrefined stories or missing acceptance criteria turn the planning event into a discovery session and blow the time-box. | The team is very small (1–2 people) and the coordination overhead exceeds the benefit — a shared to-do board reviewed daily is more proportionate. |
| Stakeholder confidence — in NZ government and regulated sectors, a documented Sprint Goal and sprint backlog gives governance bodies and assurance reviewers a clear picture of what the team is delivering and when. | Rigidity pressure — in some organisational cultures, the sprint plan is treated as a contract rather than a forecast, making the team defensive about scope change rather than adaptive. | Stakeholders insist on fixed scope and fixed dates simultaneously — surface this conflict explicitly rather than letting Sprint Planning absorb blame for an unresolvable constraint. |
Enterprise reality
How sprint planning changes at 200–300-developer scale in NZ
- Capacity and dependency data get automated. Organisations like CloudBooks and Harbour Bank use tooling (Jira Advanced Roadmaps, Atlassian Analytics) to pull historical velocity, flag inter-squad dependencies, and generate draft sprint backlogs before humans enter the room — Sprint Planning becomes a 45-minute exception-handling session, not a two-hour build-from-scratch exercise.
- Compliance work must be planned explicitly as first-class stories. Under the Privacy Act 2020 and NZISM (New Zealand Information Security Manual), teams at Revenue NZ and HealthNZ HealthNZ carry mandatory tasks each sprint — Privacy Impact Assessment reviews, security control sign-offs, and audit-log verification — that cannot be deferred without creating a regulatory gap. If those tasks are not in the sprint backlog at planning time, they will be squeezed out by feature work.
- Coordinating across 10+ squads means Sprint Planning is preceded by a Programme Increment (PI) alignment session, typically run as SAFe-style Scrum-of-Scrums or ART planning. Each squad's Sprint Goal must be stress-tested against shared platform dependencies — API versioning, shared test environments, and release train schedules — before individual squad planning begins. A squad that plans in isolation and then discovers a downstream dependency mid-sprint will stall multiple teams, not just their own.
- At PCI DSS-regulated payment teams (KiwiFirst Bank, Pacific Bank), every sprint that touches cardholder data systems requires the security and compliance engineer to attend planning. Stories in scope for PCI must be tagged at planning time so that the evidence trail — code review sign-off, penetration test scheduling, change advisory board submission — can be initiated in the same sprint rather than scrambled together the week before a release window.
◆ What I would do
Professional judgement — when to adopt Sprint Planning, when to adapt it, and what to watch for.
The bottom line: Sprint Planning is only as useful as the preparation behind it — if your planning sessions run long, the problem is almost never the planning itself; it is a backlog that was never refined, a Sprint Goal that was never written, and testing effort that was never made visible.
Best Practices
- ✓ Refine the backlog continuously — Sprint Planning should confirm, not discover; stories entering planning should already be estimated and acceptance-criteria-complete.
- ✓ Write the Sprint Goal before selecting stories, not after — it prevents the goal from becoming a retrospective justification for whatever the PO wanted anyway.
- ✓ Cap WIP in the Sprint Backlog — pull in 80–90% of capacity so the team has buffer for the unexpected without requiring a mid-sprint scope negotiation.
- ✓ Make testing tasks visible — include review, regression pass, and environment set-up tasks explicitly so testing effort is not invisible and late.
- ✓ Identify dependencies at the start — flag stories that block other teams or rely on external APIs, approvals, or environments, and surface these to the Scrum Master before the sprint starts.
- ✓ Time-box the task breakdown — spend no more than 15–20 minutes on detailed tasks per story; deep breakdown is more useful after the sprint starts when you actually know the constraints.
- ✓ Check the Definition of Done together — briefly confirm that acceptance criteria and DoD are aligned so there are no surprises at the sprint review.
- ✓ Close with a confidence check — a simple fist-to-five or thumbs poll on the Sprint Goal before ending gives the Scrum Master an early signal if commitment is shaky.
Common Misconceptions
❌ Myth: The team commits to completing every story in the sprint backlog.
Reality: The Scrum Guide is explicit — the team commits to the Sprint Goal, not to a fixed list of stories. The Sprint Backlog is a forecast. Stories can be added, swapped, or dropped (with PO agreement) if learning during the sprint reveals a better path to the goal.
❌ Myth: Sprint Planning is the time to estimate stories for the first time.
Reality: Estimating cold in a planning session is slow and produces poor estimates. Backlog refinement sessions during the previous sprint are where sizing happens; Sprint Planning confirms those estimates and adjusts if scope or context has changed. Teams that skip refinement spend 3–4× longer in planning and still leave with shakier commitments.
❌ Myth: A longer Sprint Planning session means better planning.
Reality: Sessions that run over time usually signal an unprepared backlog, unclear acceptance criteria, or unresolved architectural questions — not thoroughness. The fix is better pre-work, not more time in the room. A well-refined backlog should allow a two-week sprint to be planned comfortably in under 90 minutes.
Career level guidance
| Level | Role during Sprint Planning |
|---|---|
| Grad | Listen actively, ask clarifying questions, and volunteer for well-defined tasks within your skill area. |
| Junior | Contribute to task breakdown, estimate with the team, and flag risks or dependencies you foresee. |
| Senior | Lead technical discussion, coach others on estimation, and help shape the Sprint Goal. |
| Test Lead | Facilitate the session, challenge scope when quality is at risk, and ensure testing effort is visible in the plan. |
Senior engineer insight
The teams that get Sprint Planning right treat it as a confirmation event, not a discovery event — every story entering the room should already have acceptance criteria, a rough estimate, and at least one conversation behind it. What separates high-performing scrum teams is that they protect the Sprint Goal fiercely: when a mid-sprint surprise forces a trade-off, the goal tells you what to drop and what to protect. Teams without a real goal just thrash.
The most common mistake: testing effort is invisible. Developers task out the build work in detail and leave "testing" as a single half-hour line item — then testers are squeezed at the end of the sprint with no time to do the job properly.
From the field
A five-person scrum team at a Wellington-based government agency was consistently missing sprint goals even though planning sessions ran the full four hours. The team assumed longer planning meant better planning. When a new Scrum Master reviewed a recording of a session, the problem was clear: the first 90 minutes were spent estimating stories for the first time, in the room, cold — there was no refinement cadence at all. Testing tasks were not broken out; the testers had no idea what the regression scope would be until mid-sprint. The team introduced two 45-minute refinement sessions per week and a simple rule that no story entered Sprint Planning without estimates and acceptance criteria. Within two sprints, planning dropped to 75 minutes and sprint goal achievement went from 40% to over 80%. The lesson that transferred everywhere: time in planning is a lagging indicator of backlog health, not a sign of team diligence.
Why teams fail here
- Treating Sprint Planning as the first time stories are discussed — arriving without estimates or acceptance criteria turns a commitment event into a discovery session and blows the time-box every time.
- Writing a Sprint Goal after selecting the stories — this reverses the logic and produces a goal that is just a summary of whatever the PO wanted, giving the team nothing to trade off against when reality diverges.
- Leaving test capacity invisible — when testing is not explicitly tasked out (regression pass, environment set-up, exploratory time), testers are implicitly expected to absorb whatever is left, which is never enough.
- Committing to 100% of capacity — NZ teams are caught out by regional anniversary days, unplanned BAU support, and ad-hoc stakeholder requests; experienced teams pull in 80–85% of calculated velocity and protect the buffer.
Key takeaway
Sprint Planning done well is a 90-minute confirmation that the team understands what they are building, why it matters, and whether testing effort is honestly accounted for — not a four-hour negotiation over stories no one has looked at yet.
Self-Check
Click each question to reveal the answer.
Q: Your team is planning a sprint for an Benefits NZ online services portal and the Product Owner wants to add a high-priority story that has no acceptance criteria and has never been refined. How do you handle this in Sprint Planning?
A: Push back and ask for it to be parked for the next sprint. Stories entering Sprint Planning should already be estimated and acceptance-criteria-complete — Sprint Planning is for committing, not discovering. If the story is genuinely urgent, negotiate a 15-minute refinement slot before continuing, set a strict time-box, and accept that the estimate will be rough. Selecting an unrefined story inflates planning time and leaves the team with a shaky commitment they cannot honour reliably.
Q: What is the key difference between Sprint Planning and Backlog Refinement, and why is confusing the two a common problem on NZ government projects?
A: Backlog Refinement is ongoing and discovery-focused — the team adds detail, estimates, and acceptance criteria to future stories across the sprint. Sprint Planning is commitment-focused — it selects and locks in the work for the next sprint, assuming stories are already refined. On NZ government projects, where procurement cycles and policy sign-offs introduce stories late, teams are frequently tempted to do first-pass refinement inside Sprint Planning, which blows the time-box and produces poor estimates. The fix is a standing refinement cadence, not longer planning sessions.
Q: When would Sprint Planning be the wrong tool for the job, and what might you use instead?
A: Sprint Planning suits teams with a stable, cadenced delivery model where work can be forecast two weeks ahead. It is a poor fit for continuous-flow support teams (where work arrives unpredictably — use Kanban replenishment instead), for discovery or research phases where the solution space is too uncertain to size stories, or for very small teams where ceremony overhead exceeds the coordination benefit. In those contexts a brief daily or weekly prioritisation check-in is more proportionate and wastes less team time.
Q: A developer says "we committed to all ten stories in Sprint Planning, so we have to deliver them all." What is wrong with this and how do you respond?
A: The Scrum Guide is explicit that the team commits to the Sprint Goal, not to a fixed list of stories. The Sprint Backlog is a forecast — it can change if new information emerges during the sprint, provided the Sprint Goal is still met. The developer is conflating commitment with forecast, which removes the team's ability to adapt and creates a blame culture when reality diverges from the plan. The correct framing: the team forecasts these ten stories as the most likely path to the Sprint Goal, and scope can be adjusted with PO agreement if obstacles arise.
How this has changed
The field moved. Here is how Sprint Planning evolved from its origins to current practice.
Scrum's Sprint Planning is one of Ken Schwaber's original events. Teams select stories, break them into tasks, and commit to a sprint goal — formalising self-organisation around a time-boxed goal.
The Scrum Guide formalises Sprint Planning as a two-part event: what will be done (backlog selection) and how it will be done (task breakdown). Velocity-based capacity planning becomes the norm.
The Sprint Goal concept gets more emphasis. Teams plan toward a coherent goal rather than a collection of independent stories, creating flexibility within the sprint.
Scrum Guide 2020 simplifies Sprint Planning and increases emphasis on self-organisation and team judgement over prescribed process.
AI tools assist sprint planning by predicting capacity from historical velocity, flagging stories lacking acceptance criteria, and identifying story dependencies. The conversation about risk and uncertainty remains a human responsibility.