Backlog & agile

Sprint Planning Guide: Prep, Agenda, Sprint Goal (2026)

Run a sprint planning that works: preparation checklist, minute-by-minute agenda, a real sprint goal, commitment vs forecast, and anti-patterns to avoid.

By the RoadmapHero team · Updated on June 22, 2026 · 7 min read

Sprint planning is the meeting where a team decides what it will deliver in the next sprint and how. On paper it is simple. In practice it is where agile teams burn the most energy: four-hour marathons, tickets discovered live, estimates negotiated under pressure, and a "plan" nobody believes in by Tuesday. The fix is rarely in the meeting itself — it is in what happens before it, and in two or three habits that turn planning from a negotiation into a decision.

What sprint planning is (and is not)

In Scrum, sprint planning opens the sprint and answers three questions, in order:

1. Why is this sprint valuable? → the sprint goal.

2. What can be done this sprint? → the selected backlog items.

3. How will the work get done? → a first breakdown into tasks.

What sprint planning is not: a discovery session, a refinement session, an estimation workshop, or a status meeting. Every one of those activities has its own home. When they leak into planning, the meeting doubles in length and halves in quality. Planning consumes decisions prepared elsewhere — it does not manufacture them.

Preparation: 80% of the outcome

A sprint planning that works is mostly won before anyone joins the call. Two inputs are non-negotiable.

1. A refined backlog

The top of the backlog must arrive ready: items understood by the team, sized, with acceptance criteria and no blocking unknowns. That work happens in backlog refinement sessions during the previous sprint — never in planning itself. A practical target: at the start of planning, you have roughly 1.5 to 2 sprints' worth of ready items at the top of the backlog, so the team has real choices.

2. A known capacity

Before discussing scope, compute the team's real availability: who is on holiday, who is on support duty, which ceremonies and interviews eat time. A team of 5 with a 10-day sprint has 50 person-days on paper — but after meetings (~15%), support rotation and one person off for three days, you are closer to 35. Planning against paper capacity is the single most common cause of failed sprints. We cover the full method in our guide to capacity planning for product teams.

A minute-by-minute agenda (2-week sprint, 2 hours)

Here is a timeboxed structure that works for a team of 4–8 people on a two-week sprint:

The critical discipline is the middle block: if an item raises more than a couple of open questions, it is not ready — park it, pick the next ready item, and send the parked one back to refinement. Do not solve discovery problems in planning.

Writing a sprint goal that is not a list

"Finish PROJ-231, PROJ-245 and PROJ-250" is not a sprint goal — it is a table of contents. A real sprint goal is a single outcome the sprint exists to achieve. Compare:

• Weak: "Complete the 12 selected tickets."

• Strong: "A new user can import their Jira backlog and see it prioritized without contacting support."

• Strong: "Cut checkout page load time below 2 seconds for 95% of sessions."

A good goal does three jobs. It gives the team a decision rule mid-sprint (when something slips, protect what serves the goal, drop the rest). It makes the sprint explainable to stakeholders in one sentence. And it connects delivery to strategy — each sprint goal should trace to an initiative on the roadmap, which is exactly the difference between a roadmap and a backlog. If you cannot write a single goal, your sprint is probably two unrelated efforts stapled together; say so explicitly rather than pretending.

Commitment vs forecast

Since 2011, the Scrum Guide replaced "commitment" to a scope with forecast — and the nuance matters. The team commits to the sprint goal; the list of items is a forecast based on what is known at planning time. Treating the forecast as a contract produces exactly the behaviors you do not want: padding estimates, hiding problems until the review, and cutting quality silently to "make the number".

Practical implications:

• Judge sprints on goal achieved / not achieved, not on percentage of tickets closed.

• If new information invalidates an item mid-sprint, swap it with the PM — openly, not silently.

• Use velocity (in story points) as a planning input over 3–5 sprints, never as a performance target.

6 sprint planning anti-patterns

• The 4-hour planning. Almost always a symptom of missing refinement. Fix the input, not the meeting: items arrive ready, planning drops to 90–120 minutes.

• Tickets discovered in the meeting. If the team reads an item for the first time in planning, estimates are guesses and the forecast is fiction. Nothing enters planning that was not seen in refinement.

• Planning at 100% capacity. Zero slack means the first production incident sinks the sprint. Plan 70–80% and let the team pull more if it finishes early.

• The PM dictates the scope. The PM owns the "why" and proposes the "what"; the people doing the work own the "how much". A scope imposed on the team is a wish, not a plan.

• Vague items patched live. Writing user stories and acceptance criteria on the fly, under time pressure, with the whole team watching, is the most expensive way to write them.

• No explicit drop order. Decide at planning which items go first if things slip. Deciding under pressure mid-sprint always ends in an argument.

The 10-point pre-planning checklist

1. Top of backlog refined, estimated, acceptance criteria written.

2. At least 1.5 sprints of ready items available.

3. Team capacity computed (holidays, support, meetings deducted).

4. Velocity of the last 3–5 sprints at hand.

5. Carry-over from the current sprint identified and re-estimated.

6. Draft sprint goal proposed by the PM before the meeting.

7. Dependencies on other teams flagged and ideally resolved.

8. Key dates known (releases, freezes, demos, holidays).

9. Meeting timeboxed with an agenda visible to everyone.

10. A facilitator named who is allowed to park discussions.

Sprint planning in RoadmapHero

RoadmapHero's planning module is built to make the meeting short. Sprints and cycles sit next to the prioritized backlog, so the team pulls items that are already scored (HeroScore), estimated in story points, and linked to roadmap initiatives — the sprint goal practically writes itself. Capacity is visible per sprint, ticket health flags at-risk items, and when something slips, the White Rabbit agent proposes an automatic replanification of late tickets instead of a manual shuffle. If your developers live in Jira, Linear or GitHub, the two-way integrations keep the sprint plan and the delivery tool in sync. Free trial, transparent pricing in euros, no commitment.