Project Management for Sprint Planning

The meeting only works if the inputs are honest

Sprint planning fails in a predictable order. Someone eyeballs the backlog instead of working from a real queue. Capacity gets estimated from what the team is supposed to deliver rather than what they delivered last time. Everything gets pulled onto the board at once because nothing stops it. Two days in, the column meant to hold five items is holding eleven, and the sprint is already the thing everyone apologizes for at the next planning meeting.

None of that is a discipline problem. It is a tooling problem: the inputs to the meeting were guesses, so the output was a guess with a deadline attached.

ShipSprint changes what walks into the room. The backlog is whatever landed in triage and got sorted, not whatever someone remembers. Capacity is the team's own recent velocity, not an aspiration. And the board enforces the limit you set for it, so a sprint can't quietly overflow the moment attention moves elsewhere.

What happens in the hour before commitment

New requests don't arrive as messages to whoever seems free. They land in a triage inbox, which means the person running planning is working from one list rather than reconstructing it from three inboxes and a half-remembered hallway conversation. Sorting that list (this sprint, next sprint, not now) is most of what a good planning session actually is, and it takes minutes when the list already exists in one place.

Capacity isn't asked for, it's read off: the team's measured velocity from recent sprints is right there, so "how much can we take on" has an answer instead of a debate. And because each column carries its own WIP limit, the board itself refuses to let a sprint balloon past what was agreed. Nobody has to police it in the moment, because the limit is already set before anyone starts dragging cards.

The result is a planning meeting that spends its time on judgment calls (what matters most, what can wait) instead of on reconstructing information that already existed somewhere else. That's the trade ShipSprint is actually offering here: not a shorter meeting for its own sake, but a meeting where the thirty minutes go to decisions instead of data-gathering.

What a real session looks like

Take a ten-person team two weeks after a rough sprint: half the board still open on the last day, three items carried over with no clear reason why. The planning meeting for the next sprint starts the same way it always has: someone opens the triage inbox, and for once it isn't a surprise, because nothing has been quietly piling up outside it since the last session.

The capacity number for the sprint isn't proposed, it's read: measured velocity from the last three sprints, adjusted for two people being on leave that fortnight. Nobody argues about whether the team "should" be able to do more. The number is what it is, and the conversation moves straight to which fifteen items, in priority order, fit inside it.

As items get dragged onto the sprint board, the column's WIP limit is right there, so the moment the team tries to commit to a sixteenth item, it's visible before the meeting ends rather than three days in when someone notices the column has quietly grown to twenty-two. The meeting closes with a forecast on-screen, not a hope, and that forecast is the same one everyone will see again at the next standup if anything changes.

When planning spans more than one team

Sprint planning gets harder, not easier, the moment a sprint depends on someone outside the room: a design handoff, a platform team's API, an approval that has to come from someone who isn't in the meeting. Most of the pain in cross-team planning isn't disagreement about priority. It's that one team's capacity number is real and the other team's is a guess, because only one of them is looking at their own measured velocity.

Because capacity and WIP limits work the same way for every team on the same subscription (engineering, design, whoever else feeds the sprint) a dependency can be checked against the other team's real numbers instead of an optimistic verbal estimate given in a hallway. If the design team's own board shows their review column already at its limit, that's visible before the engineering sprint commits to work that assumes design turns something around in two days.

None of that removes the need for the conversation. It just means the conversation starts from the same set of facts instead of two teams negotiating from different pictures of reality.

What this deliberately doesn't do

ShipSprint doesn't run your planning meeting for you. It doesn't estimate story points on your behalf, tell you which ceremony to follow, or coach the team toward a "correct" cadence. Sprint length, how items get sized, whether the team calls this Scrum or something looser: that's yours to decide.

What it does is refuse to let the meeting run on bad information. The backlog, the capacity number, and the limit on each column are all facts rather than estimates, which is a smaller promise than "better planning" but a more honest one.

Walking into planning with the right things already true

• The triage inbox is empty or sorted, nothing new is sitting unseen when planning starts
• Capacity for the sprint is a number pulled from recent velocity, not a target set from hope
• No column's WIP limit is exceeded before the first day of the sprint even begins
• The forecast for the sprint is visible to whoever is committing to it, not just to whoever built the roadmap
• Anything decided about scope during the meeting is written down somewhere other than someone's memory