Sprint planning: how to run it, with an agenda

A sprint is a fixed stretch of time, usually 1 or 2 weeks, in which a team works towards one goal. Sprint planning opens it. The Scrum Guide gives the meeting 3 questions to answer:

1. Why is this sprint worth doing? The answer becomes the sprint goal: one sentence about the outcome, not a list of tasks.
2. What can be done in it? The team picks work from the top of the backlog until it has as much as it can finish.
3. How will that work get done? The first few pieces are broken into steps small enough to start the next morning.

Everything else, such as estimating, debating priorities or writing requirements, belongs before the meeting or after it.

The whole team that will do the work, and the person who decides what matters most. In Scrum that's the developers, the product owner and the scrum master. Outside Scrum it's whoever does the work and whoever sets its priorities.

The product owner brings the order: what's most valuable next. The team brings the reality: how much it can finish. Neither can plan a sprint alone. Someone with useful knowledge, like a designer or a person from support, can join for the part that needs them.

Most slow planning meetings are slow because this part was skipped. A day or two before:

• Put the backlog in order. The most important work at the top. Planning should never be the first time anyone has seen a card.
• Make the top cards clear. Enough of a description that someone could start, and a rough size. This ongoing tidying is usually called backlog refinement.
• Check who's around. Holidays, on-call weeks and part-time people change how much the team can take on.
• Look at what's left. Work unfinished from the last sprint needs a decision: continue it, or put it back in the backlog.

The Scrum Guide caps sprint planning at 8 hours for a 1-month sprint and says it's usually shorter for shorter sprints. For 2 weeks, 2 hours is plenty if the backlog is ready:

1. 10 minutes: where we are. What finished last sprint, what didn't, and who's away this time.
2. 15 minutes: the sprint goal. The product owner proposes it, the team questions it, and everyone agrees on one sentence.
3. 60 minutes: pick the work. Go down the backlog from the top. For each card ask whether it serves the goal and whether there's room. Stop when the team says that's enough, not when the time runs out.
4. 25 minutes: plan the first days. Break the first cards each person will pick up into steps. Assign them as you go.
5. 10 minutes: check and close. Read the goal and the list aloud. If anyone thinks it won't fit, take something out now.

If the meeting keeps running over, the fix is almost always earlier: a backlog that wasn't in order, or cards nobody understood.

Take on what the team can finish, not what it could start. 2 numbers help:

• What you finished recently. The amount of work completed in the last 3 or so sprints is a better guide than anyone's optimism. Teams that size cards in points call this velocity. Use it as a guide, never as a target, or the sizes will quietly grow to meet it.
• Who's actually here. If 1 of 5 people is away for half the sprint, plan for about 10% less.

Leave some room. Bugs, questions and small requests turn up in every sprint. A plan with no slack in it is already late.

A good sprint goal describes an outcome someone outside the team would care about. It gives the team a way to decide what to drop when something has to go.

• Weak: "Finish tickets 112 to 131."
• Better: "New customers can pay by card without contacting support."
• Weak: "Work on performance."
• Better: "Search results load in under a second for every customer."

If the team can't agree on one goal, the sprint is probably 2 sprints.

• Planning to full capacity. Nothing goes exactly to plan, so a full plan becomes a late one.
• No goal, just a list. When something has to give, a list doesn't say what.
• Estimating everything in detail. A rough size is enough to plan. Precision is spent better on the work itself.
• Letting work in through the side door. When something urgent arrives mid-sprint, swap it for something of the same size rather than adding it on top.
• Carrying work over without a decision. An unfinished card should be chosen again on purpose, not roll forward on its own.

A board makes the plan visible to everyone, all sprint. In craaft, the sprint planning template starts a board with Backlog, To Do, In Progress, In Review and Done:

• Before the meeting, order the Backlog column and give the top cards a size.
• In the meeting, drag the chosen cards into To Do and assign each one. To Do is the sprint.
• Write the sprint goal in the board brief, so people and agents read the same thing.
• Add a milestone for the sprint's last day. It sits beside the board with today marked.
• Put a WIP limit on In Progress so the column shows when the team has started too much.
• During the sprint, press U for standup to walk the board one person at a time.

An agent connected over MCP can help with the preparation: drafting backlog cards from a spec, or listing what's overdue before the meeting starts.