Sprint Planning Agenda Template

How to use this template

The agenda below is sized for a two-week sprint (typical timebox: 2–4 hours). For shorter sprints, scale each block proportionally. Share it with your team before the meeting so everyone arrives prepared.

Sprint Planning agenda (2-week sprint, ~3 hours)

Scaling the agenda for other sprint lengths

• 1-week sprint: target 1–1.5 hours total; compress each block by ~50 %.
• 3-week sprint: target 4–5 hours; add more time for backlog selection and task breakdown.
• 1-month sprint: Scrum Guide maximum is 8 hours; use the extra time for deeper task planning.

Pre-meeting preparation checklist

• Top backlog items are refined, with clear acceptance criteria and story-point estimates.
• The Product Owner has a Sprint Goal draft ready.
• Each Developer has checked their availability for the sprint period.
• The Scrum Master has shared the agenda at least 24 hours in advance.
• The meeting room (or video call) and a virtual planning poker tool are set up.

Running estimation during Sprint Planning

If items haven't been estimated during refinement, or if scope has changed, use planning poker in the meeting itself. Open a free online planning poker session, add the stories, vote privately, reveal together, and timebox discussion to 3–5 minutes per story.

Keep the estimation block short: if a story triggers a long debate, it likely needs to be split or deferred for a spike. Capture the open question and move on.

Adapting the sprint planning agenda to your sprint length

The Scrum Guide recommends a maximum of 8 hours for sprint planning in a 4-week sprint — roughly 2 hours per week of sprint length. This is a ceiling, not a target. Well-prepared teams with healthy backlogs routinely complete planning for 2-week sprints in 60–90 minutes.

1-week sprint agenda

Sprint Goal: 10 minutes. Item selection: 15–20 minutes. Estimation (if needed): 10 minutes. Task breakdown: 10 minutes. Close: 5 minutes. Target total: 45–60 minutes.

With 1-week sprints, the investment in preparation becomes critical — you have very little time for recovery if planning goes poorly. Stories must arrive fully refined and estimated. Backlog refinement should happen in the previous sprint.

2-week sprint agenda (most common)

Sprint Goal: 15 minutes. Item selection: 25–30 minutes. Estimation: 20–30 minutes (for unestimated items only). Task breakdown: 20–25 minutes. Commitment and close: 10 minutes. Target total: 90–120 minutes.

The 2-week cadence gives teams enough time for meaningful refinement between sprints while keeping the planning cycle short enough to maintain urgency. Most teams at this cadence settle into a reliable rhythm after 3–4 sprints.

4-week sprint agenda

Sprint Goal: 20 minutes. Item selection: 45–60 minutes. Estimation: 45–60 minutes (more stories, more unknown items). Task breakdown: 45–60 minutes. Risk review: 15 minutes. Commitment and close: 15 minutes. Target total: 3–4 hours.

4-week sprints carry higher planning risk — more things can change in a month. Compensate with more time on the risk review block and a more conservative capacity buffer (plan for 70% rather than 80%).

What each agenda block must produce

Agenda blocks without defined outputs become discussions without purpose. Assign a concrete deliverable to each block before the meeting starts so the team knows when to move on.

• Sprint Goal block: a single written sentence capturing the sprint's purpose, agreed by the full team and recorded in the tracking tool before item selection begins.
• Item selection block: a prioritised list of Product Backlog Items that the team believes fits within capacity, all linked to the Sprint Goal.
• Estimation block: story point values for all selected items that were unestimated or significantly rescoped since last refinement.
• Task breakdown block: a task list sufficient to plan the first 2–3 days of the sprint, with initial assignments for at least the first day's work.
• Commitment block: explicit verbal agreement from the team that they can deliver the Sprint Goal with the selected backlog, plus identification of the top 1–2 risks and their mitigation approach.

If a block cannot produce its required output within the allotted time, the Scrum Master pauses the meeting and identifies the root cause before continuing. The most common cause is a story that arrived without meeting the Definition of Ready.

Warning signs during sprint planning

Some patterns during sprint planning signal systemic problems that won't be resolved by better facilitation. Recognise these early and address their root causes rather than trying to work around them in the planning session itself.

• The team cannot agree on a Sprint Goal: the Product Backlog lacks strategic direction, or the Product Owner is not present and engaged. Pause and resolve before proceeding.
• Most candidate stories require significant clarification: refinement quality has dropped. The immediate fix is to defer unready stories; the systemic fix is to restructure the refinement process.
• Planning poker rounds take more than 3 rounds per story repeatedly: stories are too large, too ambiguous, or the team's shared understanding of the technology has diverged. These stories need splitting or technical research tasks before estimation.
• The team commits to exactly 100% of velocity: no buffer has been left for unexpected work, testing, code review, or interruptions. Re-negotiate to 80% before the sprint begins.
• Team members are not engaging with planning poker voting: usually a sign of facilitation problems (voting order is known), social pressure (senior team members vote first in discussion), or a tool that isn't working correctly.

Related guides and resources

• What Is Sprint Planning in Scrum?
• How to Run a Scrum Sprint Planning Meeting
• Scrum Planning overview
• Planning Poker guide
• How to use Planning Poker step by step
• Launch a free planning poker session