Sprint planning has one job that gets skipped constantly: deciding not just what the team will work on, but whether that amount of work actually fits in the time available. A meeting that only picks tickets off the top of the backlog is not sprint planning, it is a to-do list with a date stamped on it. Real sprint planning answers two questions together — what can realistically get finished, and what the plan is for finishing it.
What changed in 2026
- AI backlog grooming assistants pre-flag unready stories before the meeting, cutting down on the live refinement that used to eat up planning time.
- Async pre-planning refinement became standard, with the product owner and a few engineers clarifying acceptance criteria days ahead so the live session is shorter and more decisive.
- Capacity planning tools now account for meeting load and support rotations automatically, instead of teams estimating capacity by headcount alone and being surprised when it does not hold up.
What sprint planning needs to produce
By the end of the meeting, the team should have a sprint goal, a list of committed tickets sized against real capacity, and clarity on anything that is blocked before it starts. Missing any one of these turns the sprint into a loose collection of tasks rather than a coordinated push toward something specific.
How to run the meeting
- State the sprint goal first, before looking at individual tickets. The goal should connect to a larger OKR, not exist in isolation.
- Confirm capacity for the sprint, accounting for meetings, on-call, time off, and any known interruptions, not just raw headcount.
- Pull already-refined tickets from the backlog that serve the sprint goal, in priority order.
- Have the team estimate or confirm sizing on each ticket, flagging anything unclear enough to need more refinement before it is pulled in.
- Stop pulling in tickets once capacity is reached — resist the pressure to overcommit because a ticket looks quick.
- Confirm the final list out loud so everyone leaves agreeing on the same commitment.
Estimating capacity honestly
| Factor |
Effect on capacity |
| Meetings and ceremonies |
Reduces available hours, often by 20 percent or more |
| Time off and holidays |
Subtract directly per person for the sprint |
| On-call or support rotation |
Reduces capacity for whoever is on rotation that sprint |
| Carryover from last sprint |
Counts against this sprint capacity, not a bonus addition |
| New team member ramping |
Reduce their contribution, do not count them at full capacity |
Common sprint planning mistakes
Refining tickets live during planning. This is the single biggest cause of sprint planning meetings running long. Refinement is a separate, earlier conversation.
Sizing the sprint by headcount instead of real capacity. A five-person team is rarely five days times five people of actual output once meetings, interruptions, and support work are subtracted.
No sprint goal. Without one, the sprint becomes a bucket of unrelated tickets, and it becomes hard to tell whether the sprint succeeded or just happened.
FAQ
How long should sprint planning take?
Roughly one to two hours per week of sprint length is a common rule of thumb, so a two-week sprint often runs a planning meeting of one to two hours, assuming refinement already happened beforehand.
Who should attend sprint planning?
The full delivery team, plus the product owner. Stakeholders outside the team generally do not need to be in the room for this particular meeting.
What happens to tickets that do not get finished?
Ask why before automatically carrying them forward. If the same type of ticket repeatedly does not finish, the estimation process or the ticket sizing needs a look, not just the individual ticket.
Should sprint planning include bug fixes and support work?
Yes, explicitly. Unplanned support work that is not accounted for in capacity is one of the most common reasons sprints consistently miss their commitments.
Where to go next