Sprint Planning Meeting: Agenda and Template

A sprint planning meeting agenda follows the three topics the Scrum Guide sets: why this Sprint is valuable, what can be Done in it, and how the chosen work will get done. The whole Scrum Team agrees a Sprint Goal, the Developers select items from a refined backlog with the Product Owner, and then plan the first pieces of work. The Scrum Guide caps it at eight hours for a one-month Sprint and says it is usually shorter for shorter Sprints. For a two-week Sprint on a small team with a well-refined backlog, around two hours is a common target.

This page is about running the meeting. For using an AI assistant to prepare for it, see sprint planning with AI.

What the Scrum Guide sets

The 2020 Scrum Guide↗ (opens in a new tab) says Sprint Planning initiates the Sprint by laying out the work to be performed, and that the plan is made by the entire Scrum Team. The Product Owner makes sure attendees are ready to discuss the most important Product Backlog items and how they map to the Product Goal, and the team may invite other people to give advice. It addresses three topics:

1. Why is this Sprint valuable? The Product Owner proposes how the product could increase its value, and the whole Scrum Team defines a Sprint Goal that says why the Sprint is valuable to stakeholders. The goal must be finalised before the meeting ends.
2. What can be Done this Sprint? Through discussion with the Product Owner, the Developers select items from the Product Backlog. The team may refine items as it goes. The more the Developers know about their past performance, their upcoming capacity and their Definition of Done, the more confident their forecast.
3. How will the chosen work get done? For each selected item the Developers plan the work needed to meet the Definition of Done, often by breaking items into pieces of one day or less. How they do that is up to them alone.

The Sprint Goal, the selected items and the plan together are the Sprint Backlog. The timebox is a maximum of eight hours for a one-month Sprint; for shorter Sprints the event is usually shorter. The “why” topic was given its emphasis in the 2020 revision; older templates that only cover what and how are missing the part that holds the Sprint together.

Inputs: what to bring

• A refined Product Backlog, ordered, with the top items small enough to finish within the Sprint. Refinement happens before the meeting, not in it.
• The Product Goal, so the Sprint Goal has something to serve.
• The latest Increment and what was learned at the last Sprint Review.
• Capacity for this Sprint: holidays, support rota, anything else that takes people away.
• Past performance: how much the team actually finished in recent Sprints, as items counted or as whatever sizes it uses.
• The Definition of Done, because it decides how much work each item really is.
• Improvements agreed at the last Retrospective, some of which may belong in this Sprint.

Outputs: what to leave with

• A Sprint Goal: one sentence the team can make trade-offs against when something unexpected lands.
• The selected Product Backlog items, which are a forecast, not a promise of every item.
• A plan for at least the first few days, with the first items broken into pieces of a day or less. The rest can be planned as the Sprint goes.
• Questions still open, each with a name against it.

A timed agenda for a two-week Sprint

This is a practice many small teams use, not a rule. It assumes five to eight people and a backlog refined in the previous week. Scale it down rather than filling time.

1. 0:00 to 0:10. Context. The Product Owner recaps the Product Goal, what the last Review changed and anything new from stakeholders. Someone states capacity for this Sprint.
2. 0:10 to 0:30. Why. The Product Owner proposes an objective; the team debates it and agrees a draft Sprint Goal in one sentence.
3. 0:30 to 1:10. What. Walk down the ordered backlog. For each item, ask whether it serves the goal and whether it is ready. Stop when the forecast reaches what past performance and capacity support, not before and not beyond.
4. 1:10 to 1:50. How. The Developers break the first items into tasks of a day or less, spot dependencies and decide who starts where. The Product Owner stays to answer questions.
5. 1:50 to 2:00. Close. Re-read the Sprint Goal against the selection. If the items do not serve it, change one or the other. Confirm the open questions and who owns each.

If the “what” section keeps overrunning, the backlog was not ready: the Agile Alliance’s entry on sprint planning↗ (opens in a new tab) names inadequate refinement as the first common pitfall, with time spent understanding items instead of selecting from ready ones. The fix is a backlog refinement session in the days before, not a longer planning meeting.

A sprint planning template

Copy this into your notes or the board and fill it in during the meeting. Keep it to one screen.

Sprint: 14   Dates: 6 Oct to 17 Oct
Product Goal: <one line>

Capacity
- Days available: <e.g. 5 people x 9 days, minus 4 days leave>
- Finished in the last three Sprints: <e.g. 11, 9, 12 items>

Sprint Goal (why)
<one sentence a stakeholder would understand>

Selected items (what), in order
1. <ref> <title> - serves the goal because <...>
2. ...
Not selected, but next if there is room: <refs>

Plan (how), first days
- <ref>: <first task, one day or less> - <who starts>
- Dependencies: <...>

Open questions
- <question> - <owner> - <needed by>

Retrospective actions taken in: <refs>

Common failures

• No Sprint Goal, or a goal that is just the list of items. The Agile Alliance notes that without a goal, teams accumulate unrelated work and finish tasks without meaningful progress.
• Refining in the meeting. Discovering what an item means takes far longer with the whole team watching.
• Filling to capacity. A plan with no slack breaks on the first surprise. Leave room, and let the Sprint Goal decide what gives.
• Someone else sizing the work. The Scrum Guide gives sizing to the Developers who will do it; a manager’s numbers make a forecast nobody owns.
• Planning every task up front. Plan the first days in detail and the rest as it comes; the Scrum Guide expects the Sprint Backlog to change as more is learned.
• Treating the forecast as a contract. The goal is the commitment; the items are the team’s best guess at how to reach it.
• Arguing over estimates. If sizing takes most of the meeting, see whether you need story points at all.

The GOV.UK Service Manual’s page on agile tools and techniques↗ (opens in a new tab) sums up the same meeting in one line: at the start of each sprint the team decides what to work on next and how they will do it, and the length depends on how long the sprint is. Everything above is detail on that sentence.

Sprint planning on a fenbs board

fenbs has no sprints, no Sprint Goal field, no story points and no due dates. It has four fixed lanes, To Do, Next Up, In Progress and Completed, and those are enough to carry a Sprint if you agree what each lane means.

• To Do is the Product Backlog. Priority runs 1 to 10, with 1 the most urgent, and on a team board the Shared order is the exact order everybody sees.
• Next Up is the Sprint selection. At the end of the “what” topic, move the selected tasks into Next Up and drag them into order. Anything left in To Do is not in this Sprint.
• Sizes are optional letters from XS to XL. An XL in Next Up means the item was not ready: split it before the meeting ends.
• The Sprint Goal and other choices made in the room go on the Decisions page, with who decided and why, so people and AI assistants working later in the Sprint can read what it is for.
• Each task’s plan box holds the “how” for that item, and a category named after the Sprint, such as “Sprint 14”, lets you filter to it later.
• Moving tasks between lanes is its own permission, so an assistant connected with read and comment access cannot change the selection.