How to Run Sprint Planning

Two decisions, not one

Sprint planning is the recurring meeting at the start of each sprint where a team decides what it will work on for the next one to three weeks. It has two distinct outputs that get run together far too often: a sprint goal, which is a sentence describing why this sprint matters, and a sprint backlog, which is the specific list of items the team is committing to finish. Skipping the first and going straight to the second is the most common reason sprints end up as an unrelated pile of tickets nobody could summarize in one sentence.

Done properly, the meeting ends with both: a goal the whole team could repeat back, and a backlog sized against real capacity rather than optimism.

Setting the sprint goal first

Start with the goal, before touching the backlog. A sprint goal is a short statement of intent, something like "reduce checkout failures for mobile users," not a list. Its purpose is to give the team something to make trade-off decisions against mid-sprint: if something unplanned comes up, does it serve the goal or not? Teams without a stated goal end up treating every item on the board as equally important, which makes triage during the sprint effectively impossible.

A goal that's just a restatement of the backlog, something like "complete the items listed below," isn't doing this job. If you can't tell, from the goal alone, what the sprint would have looked like if it had gone differently, it's not specific enough yet.

Committing to capacity, not hope

The backlog half of the meeting is where over-commitment happens, and it happens for a predictable reason: it's socially easier to agree to one more item than to say no in front of the team. The fix is to make the constraint external rather than a judgment call in the room: capacity is a number, calculated before the meeting from actual availability, and the backlog fills up to that number and then stops. Once the number is spent, the next item goes back in the backlog, not into "we'll try."

This is also where last sprint's completed total earns its keep. A team that committed to 40 points and finished 28 has a real capacity of roughly 28, not 40, whatever the individual estimates said. Planning the next sprint against the committed number rather than the completed number is the most common single cause of sprints that consistently run over. It's optimism wearing a spreadsheet.

What actually gets pulled in

Pull order matters. Anything tied to the sprint goal comes first, in priority order, until capacity is spent: not the easiest items, not the ones a particular engineer wants to do, and not everything half-started from last sprint by default, though genuinely unfinished carry-over usually deserves priority since it's already partly paid for. Items with unresolved dependencies on another team, or without enough detail to size confidently, should not go in even if there's room; an item pulled in on hope tends to sit untouched until day eight while everyone waits on something outside the team's control.

If capacity runs out with the sprint goal only partly covered by fully-scoped work, that's useful information to surface in the meeting, not to paper over. It usually means the goal was too ambitious for the sprint length, or the backlog wasn't refined enough going in, and both are worth fixing before the next planning session rather than during this one.

Before you close planning, check

• Could everyone in the room repeat the sprint goal in one sentence?
• Is the backlog sized against actual availability, not headcount?
• Does the total reflect what was actually completed last sprint, not committed?
• Is there room left for unplanned work, or is the sprint booked solid?
• Does every pulled-in item have enough detail to start without more clarification?

A sprint that fails the last check tends to fail quietly: not by missing the deadline outright, but by everyone discovering mid-sprint that half the items needed a conversation nobody had scheduled.

A note on where the capacity number comes from

The capacity math above gets easy once it stops depending on anyone's memory of who was busy last sprint. ShipSprint plans boards against real logged capacity rather than a guess, with per-column work-in-progress limits so a sprint can't silently absorb more than the team has room for, and delivery forecasts calculated from the team's own measured velocity rather than a fresh estimate every time. It doesn't replace the conversation about the goal (that's still a human judgment call), but it takes the guesswork out of the capacity half of the meeting.