Sprint Planning Template

The sprint planning template turns a backlog into a focused plan the team can commit to. A good plan answers two questions: what can we deliver this sprint, and how will we get the work done. This agenda walks both halves in order so the team leaves with a clear sprint goal and a realistic forecast.

When to use it

Run sprint planning at the start of every sprint, before any new work begins. Budget roughly two hours for a two-week sprint and scale up or down with sprint length. Going in, the backlog should already be refined so planning is selection, not discovery.

Who attends

The Product Owner brings priorities and the proposed goal. The Scrum Master facilitates and guards the timebox. The development team forecasts the work and owns the commitment. Everyone who will do the work should be in the room.

How to run it

Start with capacity so the plan is grounded in real availability. Next, lock a single sprint goal that gives the work meaning. Walk the top of the refined backlog, confirm acceptance criteria, and clear open questions. Then let the team pull items that fit capacity and serve the goal. Decompose those items into tasks, surface dependencies, and close by restating the goal and confirming the team believes the forecast is achievable.

Facilitator tips

• Protect one sprint goal so the sprint has a clear theme, not a grab bag.
• Let the team pull work rather than having a manager assign it.
• Use real capacity that accounts for time off, meetings, and support load.
• Refine before you plan so this session is fast and decisive.

Common mistakes

• Overcommitting because capacity ignored meetings, support, and time off.
• Planning unrefined items so the meeting turns into discovery and runs long.
• Skipping the sprint goal and ending with a disconnected list of tasks.
• Letting the Product Owner dictate the forecast instead of the team.

Want planning that sticks? Run it in OrgTP to keep the sprint goal, backlog, and commitment visible to the whole team.