Run· Mixed

Run a sprint planning meeting that doesn't suck

9-step playbook for sprint planning that takes 60 minutes, ends with a real commitment, and the team actually ships what they said they would.

Open in DockEng managers + tech leads + PMs

Most sprint planning meetings are 3-hour status updates that end with no real commitment. The fix: planning is async-prepped, the live meeting is 60 minutes max, and the output is a written sprint plan with one owner per item, a sprint goal, and a slack budget. This playbook walks the 9 steps that make planning lightweight enough that the team will actually do it, week after week, without the dread.

Outcome

A 60-minute sprint planning meeting that ends with a written plan, a sprint goal, one owner per item, and a slack budget. The team ships what they committed in 80%+ of sprints because the commitment was honest.

Time60 min meeting + 1-2 hr async prep, every sprintDifficultybeginnerForEng managers and tech leads running 2-week sprints with a 2-8 person team.

What you'll need

Pre-register or install before you start.

LinearFree for up to 10 users, $8/user/mo Standard

Track issues, sprints (cycles), and capacity. Best-in-class for small teams.

JiraFree up to 10 users, $7.53/user/mo Standard

If you're already on Atlassian. More configurable than Linear, more friction.

LoomFree for 25 videos, $15/creator/mo Business

Record a 5-minute walkthrough of the proposed sprint plan for async review.

Dock or shared docsFree tier, $19/mo Pro on Dock

Host the sprint plan, capacity log, and retro notes in one workspace.

The template · 9 steps

Top to bottom. Each step has tasks, pointers, gotchas.

Async prep: groom the backlog 2 days before planning

1-2 hr async, 2 days before planning

Sprint planning meetings drag because the backlog isn't ready. Spend an hour 2 days before planning: read every candidate issue, kill the dead ones, write specs on the fuzzy ones, estimate the clear ones. The meeting itself is a commitment ceremony; the thinking happens before.

Tasks

Open the backlog in your tracker
For each candidate: is it clearly written? does it have a description, acceptance criteria, an estimate?
Kill any issue older than 60 days that no one has championed
Write or refine the description for the top 10-15 candidates
Note dependencies between issues; flag any that need design or research before they can ship

Pointers

GuideAtlassian: backlog grooming

Gotchas

Backlogs that grow without grooming become tombstones. Kill aggressively; if it matters, someone will re-file.
An issue without acceptance criteria can't be honestly estimated. Write the criteria in grooming, not in the meeting.

Calculate the team's actual capacity for the sprint

30 min

Capacity is not 'team_size times sprint_length'. It's net of vacation, on-call burden, meeting overhead, the senior engineer who is helping new hires. Calculate honestly per person: how many engineering-days are they actually on the keyboard this sprint?

Tasks

List each engineer + their nominal days in the sprint (e.g. 10 days for a 2-week sprint)
Subtract: vacation days, holidays, on-call days, training days, big-meeting days
Subtract: estimated meeting overhead (rough rule: 20% of remaining days)
If anyone is part-time on this team, multiply by their FTE
Sum: the team's total engineering-days for the sprint
Append to Capacity log: total engineering-days available this sprint

Pointers

GuideVelocity vs capacity (Mike Cohn)

Gotchas

The team that always plans for 100% of nominal capacity always misses commitments. 60-70% of nominal is honest; the rest is meeting overhead, support, and unplanned work.
On-call engineers are at 30-50% productivity during their on-call week. Don't count them as full FTE.

Define a single sprint goal in one sentence

15 min

A sprint goal is what the team is trying to accomplish this sprint as a coherent unit. 'Ship the new checkout flow to 10% of users' is a goal. 'Complete 12 tickets' is not. Goals make trade-offs decidable mid-sprint when something unexpected lands.

Tasks

Look at the candidate work and the team's current OKRs / quarterly priorities
Write a 1-sentence sprint goal that captures the most important outcome
Verify: does every committed issue contribute to this goal? Issues that don't may still be in the sprint, but they're explicitly 'not the goal'
Pin the goal at the top of the sprint plan doc so it's visible all sprint

Pointers

OfficialScrum Guide: sprint goal

Gotchas

A sprint goal that's just 'ship our planned work' is decoration. The goal should answer 'why this sprint, why now'.
If you can't write a goal that ties more than 50% of the sprint's work together, the work is too scattered and you should drop the bottom half.

Agent prompt for this step

Read the candidate work for this sprint and the team's current quarterly OKRs.

Draft 3 candidate sprint goal statements. Each should:
1. Be 1 sentence, under 20 words.
2. Name a measurable outcome (a feature shipped, a metric moved, a milestone hit).
3. Tie back to a quarterly OKR if possible.

Output as a numbered list. Then propose the strongest of the three with rationale.

Run the planning meeting in 60 minutes flat

60 min meeting

Hard cap: 60 minutes for a 2-week sprint, 90 minutes for a 3-week sprint. Anything longer is the prep wasn't done. The meeting is for collective commitment, not for thinking from scratch. Walk through the proposed plan, debate the close calls, agree on the goal.

Tasks

Start by stating the proposed sprint goal (2 min)
Walk through the candidate items: each engineer says 'yes I can own this' or 'I have concerns'
Discuss only the close calls (3-5 items max); don't re-read every issue
Sum up: committed items, total estimate, capacity check
End with each engineer naming what they own and what they're working on first

Gotchas

Meetings that go past 60 min lose the room. Hard-cap, defer ambiguous items to next sprint, don't over-commit.
Silence in a planning meeting usually means 'I have concerns but this is awkward'. Ask each engineer specifically; don't accept group nods.

Reserve 20% slack for unplanned work

Built into the meeting

Every sprint has unplanned work: a customer-reported bug, a production fire, a new task from the CEO. Reserve 20% of capacity for it explicitly. If the slack is unused, the team finishes the sprint early; if it's used, the team still ships the committed plan. Teams that plan to 100% always miss.

Tasks

From the team's total engineering-days, subtract 20% as 'slack' before committing items
Document the slack budget in the Sprint plan doc: '8 engineering-days reserved for unplanned'
Mid-sprint: check how the slack is being used; flag if exceeded
End of sprint: review the slack usage in retro - was 20% right?

Pointers

GuideSlack: getting past burnout (Tom DeMarco)

Gotchas

The pressure to commit to more than your capacity is constant. Resist it; the team's credibility is built by hitting commitments, not by promising more.
Slack budget that's never used is a sign the team is overcommitting elsewhere or the work is being done off the clock. Investigate.

Ensure every committed item has a single owner

Built into the meeting

Items without a single owner stay un-started. 'The team' is not an owner. Every issue gets one engineer's name on it before the meeting ends. That engineer commits to driving it - which doesn't mean doing it solo, just being the one who chases blockers and surfaces problems.

Tasks

For each committed issue, name a single owner (assignee in your tracker)
If no one volunteers, the EM/TL assigns - don't leave items unowned
The owner is responsible for: starting the work, surfacing blockers in standup, marking done when shipped
If an issue genuinely needs co-ownership, name a primary; the second person is consulted

Gotchas

Co-owned items become un-owned items. Single primary owner; secondary is for context, not for doing.
Owners who go on vacation mid-sprint orphan their items. Pair owners with backups for critical work.

Run a 15-minute mid-sprint check-in

15 min, mid-sprint

Mid-way through the sprint, take 15 min to check progress. What's done, what's in progress, what's stuck. If the team is materially off-track (>30% behind plan), this is the moment to drop scope, not Friday afternoon.

Tasks

Schedule for the morning of the middle day of the sprint (Wednesday in a 2-week Mon-Fri sprint)
Each engineer: 1 min on done items, in-progress items, blockers
Identify any item that's >50% over estimate; decide: keep pushing, drop, descope
Update the Sprint plan doc with mid-sprint adjustments
If material change in scope, communicate to stakeholders in writing same day

Gotchas

Skipping the mid-sprint check-in is how teams discover at sprint-end they're 40% short. The 15 min is cheap insurance.
Standup is not the mid-sprint check-in. Standup is daily blockers; mid-sprint is scope reassessment.

Run a 30-minute sprint retro at sprint end

30 min, end of sprint

Retros are the only thing that compounds week to week. The same team running a retro for 12 sprints in a row is materially better at planning by sprint 12 than by sprint 1. 30 minutes max. Three questions: what worked, what didn't, what will we do differently. Action items must have an owner.

Tasks

Each team member: 1 thing that worked, 1 thing that didn't, 1 thing to try differently
Group similar themes; pick 1-3 action items max
Each action item has a single owner and a deadline (often 'by next sprint planning')
Append to Capacity log: planned vs delivered, retro themes
Track the action items; revisit at the next retro

Pointers

GuideAtlassian: retrospective playbook GuideProject Aristotle (psychological safety)

Gotchas

Retros that turn into blame sessions destroy team trust. Lead with 'what worked'; treat what didn't as system bugs, not person bugs.
Action items without owners die in the retro doc. Every item gets one name and a date.

Agent prompt for this step

Read the Capacity log row for the just-completed sprint and the Sprint plan doc.

Draft a retro starter pack:
1. Numbers: planned items vs delivered items, capacity used vs slack budget, % of plan completed.
2. 3-5 candidate retro topics based on variance: items that took materially longer than estimated, items that were dropped, blockers that recurred from past retros.
3. 3 candidate action items the team might commit to (small, owner-assignable, completable within next sprint).

Output as a Markdown section to paste into the retro doc. The team picks what to discuss; you propose the starting points.

Track velocity, but don't worship it

5 min/sprint

Velocity (story points or items per sprint) is useful for capacity calibration. It's not useful as a performance metric, and treating it as one corrupts it (engineers inflate estimates to look fast). Track it for 6+ sprints to find the team's honest baseline; use that baseline to plan the next sprint's capacity.

Tasks

After each sprint, append the delivered items / story points to Capacity log
After 6 sprints, calculate the rolling average: that's your honest velocity
Use the rolling average to validate next sprint's commitment (within 20%)
Resist comparing velocity to other teams or other quarters - context dependent

Pointers

GuideMike Cohn: velocity is for the team

Gotchas

Velocity used as a manager-to-team performance metric becomes Goodhart's Law: estimates inflate to make velocity look good. Use it as a planning tool only.
A team's velocity doubles when senior engineers join and halves when they leave. Don't expect it to be steady; expect it to track team composition.

Hand the template to your agent

Workspace-wide agent prompt.

Paste this into your agent's permanent system prompt so the agent reads, writes, and maintains the template's surfaces as you work through the steps.

Agent system prompt

You are an agent on the "Run a sprint planning meeting" playbook workspace.

Your role: maintain the four surfaces (Steps, Pointers, Sprint plan, Capacity log) every sprint.

Cadence:
- 2 days before planning: read the backlog and the prior sprint's outcomes; draft the candidate sprint plan in the Sprint plan doc.
- During planning: append decisions to the Sprint plan doc as they're made.
- After planning: append a row to Capacity log with planned story points / items / owners.
- Mid-sprint: check progress against the plan; flag in the Brief any item more than 50% over estimate.
- End of sprint: append delivered count to the Capacity log row, propose retro topics from variance.

First MCP tool calls:
1. list_surfaces(workspace_slug="run-a-sprint-planning-meeting")
2. list_rows(workspace_slug="run-a-sprint-planning-meeting", surface_slug="capacity-log")
3. get_doc(workspace_slug="run-a-sprint-planning-meeting", surface_slug="sprint-plan")

Don't overload the sprint - if planned exceeds historical velocity by more than 20%, raise it explicitly.

FAQ

Common questions on this template.

How long should sprint planning actually take?: 60 minutes flat for a 2-week sprint with a 2-8 person team. 90 minutes for 3-week sprints. Anything longer is the async prep wasn't done, or the team is rebuilding the backlog in real-time. The fix is always more grooming before the meeting, not a longer meeting.
Are sprints even worth it for a small team?: For a 2-3 person team that's mostly co-located and aligned, often no - lightweight kanban (a board, daily standup, weekly review) covers the same ground without ceremony. For a 4-8 person team, especially if remote or async, sprints provide a useful commitment cadence and a natural retro rhythm. Bigger than 8 and you're past sprint-planning-as-one-meeting; you're into multi-team coordination.
What's the most common reason sprints miss?: Two: (1) capacity was overstated - the team planned for 100% of nominal capacity and reality delivered 60-70%; (2) the work was estimated without acceptance criteria, so engineers discovered scope mid-sprint. Fix capacity by reserving 20% slack and being honest about non-engineering time. Fix scope by writing acceptance criteria in grooming, not in the sprint.
Should I use story points or hours?: For a small team starting out: just use 'items' (count of issues completed). Story points add overhead that mostly pays off when you have 3+ teams comparing capacity. Hours encourage false precision. If the team is mature and wants finer granularity, Fibonacci-style story points (1, 2, 3, 5, 8) work better than hours because they explicitly encode uncertainty.
Can my AI agents help with sprint planning?: Yes. Agents are useful for: drafting the candidate sprint plan from the backlog, summarising the prior sprint's variance to feed retro, identifying stale issues for backlog grooming, drafting the sprint goal from the team's quarterly OKRs, and tracking action items between retros. The judgement calls (what to commit, what to drop, capacity, ownership) need humans. The playbook ships agent prompts inline for the goal-drafting and retro-prep steps.

Open this template as a workspace.

We mint a fresh copy in your org with the steps as table rows, the pointers as a separate table, and the brief as a doc. Bring your agents, start checking off boxes.

Open in Dock