If your sprints regularly end with half the board still in progress, the problem usually isn't the team's effort, it's what happened in the planning meeting two weeks earlier. This guide walks through the mechanics that make sprint planning actually work: grooming the backlog ahead of time, sizing capacity around real available hours, estimating consistently, and committing to one clear goal instead of a grab-bag of tickets.
In this guide
What sprint planning is actually for Groom the backlog before the meeting, not during it Plan capacity around real available hours Pick an estimation approach and stay consistent Set one sprint goal, not a pile of unrelated tickets The client-services trap: uncounted support hours A sprint planning checklist worth keeping Frequently asked questions
What Sprint Planning Is Actually For
Sprint planning has one job: turn a backlog of possible work into a specific, achievable commitment for the next one or two weeks. That sounds obvious, but most teams treat the meeting as a scheduling exercise, pulling tickets off the top of the backlog until the sprint "looks" full, rather than a capacity exercise grounded in what the team can realistically finish.
The difference matters because a sprint plan is a promise, to the rest of the business, to a client, or to whoever is waiting on the next release. A plan built on wishful thinking breaks that promise almost every time, and a team that consistently misses its own sprint commitments stops trusting the process altogether. The fix isn't more discipline in execution, it's a planning meeting that starts from real numbers instead of optimism.
Groom the Backlog Before the Meeting, Not During It
The single biggest time sink in sprint planning is discovering, mid-meeting, that half the tickets on the table aren't actually ready: the acceptance criteria are vague, nobody has estimated them, or a dependency on another team hasn't been confirmed. When that discovery happens live, planning turns into an impromptu grooming session, and a meeting that should take an hour stretches into three.
Backlog grooming, sometimes called refinement, needs its own slot earlier in the sprint, ideally a standing session a few days before planning. In that session the team writes clear acceptance criteria, breaks oversized tickets into something a person can finish in days rather than weeks, flags dependencies, and estimates the work. By the time planning starts, every candidate ticket should already be a known quantity. The planning meeting itself then becomes what it should be: deciding how many of those known quantities fit into the available capacity, not debating what a ticket even means.
Plan Capacity Around Real Available Hours, Not Headcount
The second most common failure mode is treating capacity as a headcount multiplication problem: five engineers, two weeks, therefore X story points. That math assumes everyone is available at 100% for the entire sprint, which almost never happens once you subtract meetings, code review, onboarding a new hire, a planned day off, or a public holiday that falls mid-sprint.
A more honest approach starts from actual available hours per person for that specific sprint. Take each person's working hours, subtract confirmed time off, recurring meetings, and any known non-project commitments, and you get a realistic hours figure, not a theoretical one. Teams that already track time against projects have an advantage here: instead of guessing at availability, they can look at what people actually logged in the last several sprints and use that as a baseline. This is one place a connected platform pays off, when time tracking, attendance, and project planning live in the same system, as they do in Autovella, capacity for the next sprint can be built from real historical data rather than a spreadsheet someone updates by memory.
Once you have real available hours, convert them into a capacity figure using your team's own historical throughput, not an industry rule of thumb. If the team has completed roughly 40 story points per sprint over the last several sprints at typical availability, that number, adjusted for this sprint's known absences, is a far better planning input than headcount times a flat estimate.
Pick an Estimation Approach and Stay Consistent
Teams argue endlessly about which estimation method is "correct." The honest answer is that consistency matters more than the specific unit. Story points using a Fibonacci-like scale (1, 2, 3, 5, 8, 13) work well because the growing gaps between numbers force real conversation about complexity rather than false precision. T-shirt sizing (S, M, L, XL) is a reasonable lighter-weight alternative for teams that want relative sizing without numbers. Ideal days, estimating in units of focused work time, can work too, as long as everyone agrees it means focused hours, not calendar days.
Whichever method you choose, run it as a group activity rather than one person's guess. Planning poker or a quick round of silent voting surfaces disagreement early, someone who sizes a ticket at 2 points while another sizes it at 8 usually knows something the other person doesn't, and that gap is worth surfacing before the ticket enters a sprint, not after it's already blown past its estimate.
Resist the temptation to re-calibrate your scale every few sprints or to compare points across teams. Points are only useful as a relative, internal yardstick measured against your own team's past performance, not as an absolute unit of effort that means the same thing everywhere.
Set One Sprint Goal, Not a Pile of Unrelated Tickets
A sprint stuffed with disconnected tickets, a bug fix here, an unrelated feature there, a task someone asked for last week, gives the team nothing to rally around and no way to make a smart trade-off when something goes sideways mid-sprint. A sprint built around one clear goal, such as "ship the updated checkout flow" or "resolve the top three reliability issues from last month," gives every ticket in the sprint a reason for being there.
The goal also becomes the decision-making tool you need when reality intrudes. If a ticket turns out to be bigger than estimated, or an urgent request lands mid-sprint, the question isn't "do we have time," it's "does this serve the sprint goal." Tickets that don't can be pushed to the next sprint without much debate; tickets that do get priority even if something else has to slip. Without a stated goal, every one of those calls becomes a fresh argument.
Write the goal in one sentence, put it at the top of the sprint board, and have the team confirm out loud, before the meeting ends, that the committed tickets actually add up to that goal. If they don't, either the goal or the ticket list needs to change before anyone leaves the room.
The Client-Services Trap: Uncounted Support Hours and Calls
Software teams inside agencies, consultancies, and IT services firms fall into a specific version of the overcommitment problem that pure product teams rarely face: support tickets and client calls don't show up on the sprint board, so they don't show up in capacity planning, but they absolutely consume the hours the sprint is counting on. A developer who is nominally "full-time on the sprint" might lose six or eight hours a week to a client escalation, a status call, or an urgent fix for a different account entirely, and none of that gets subtracted before the sprint commitment is made.
The result is predictable: the sprint plan looks reasonable on paper, and the team still misses it, sprint after sprint, while everyone assumes the estimates must be wrong. The estimates are usually fine. The capacity number was never real to begin with.
The fix is to budget for interruptions explicitly, not hope they don't happen. Look at how many hours support work and client calls actually consumed in the last several sprints, using logged time rather than guesswork, and subtract that figure from capacity before you commit to anything. Teams that track time against both project work and support work in one place, which is exactly what time tracking and attendance in Autovella are built to surface, can see this pattern clearly instead of discovering it after the sprint has already slipped.
Some teams go further and reserve a fixed buffer, for example planning at 80% of theoretical capacity for a client-facing team versus 95% for a team with no support load, so the buffer is built into the plan rather than absorbed as unplanned overtime.
A Sprint Planning Checklist Worth Keeping
Most planning meetings run long or run poorly for the same handful of preventable reasons. A short checklist, reviewed before the meeting starts, keeps the session focused on decisions rather than discovery:
- Backlog groomed and estimated ahead of time, with acceptance criteria written on every candidate ticket
- Real available hours calculated per person for this specific sprint, not assumed at 100%
- A buffer set aside for support tickets, client calls, and other unplanned interruptions
- A one-sentence sprint goal drafted before the meeting, ready for the team to react to
- Dependencies and blockers flagged and, where possible, resolved before commitment
- Committed points checked against recent historical throughput, not against what would be nice to finish
None of these steps take long individually. Skipping them is what turns a one-hour planning meeting into a two-hour argument.
Why Sprint Accuracy Matters More Than Raw Velocity
Velocity, the raw number of points completed per sprint, gets watched obsessively because it's easy to graph, but it's a poor signal on its own. A team can hit a high velocity number by quietly padding estimates, and a team's velocity naturally rises as it learns to estimate more generously, without delivering any more real value.
Sprint accuracy, the ratio of what was completed to what was committed at the start of the sprint, is a healthier number to track because it measures the thing that actually matters: whether the plan can be trusted. A team consistently landing at 85 to 95% sprint accuracy is planning well, regardless of whether its raw velocity is 30 points or 80. A team hitting 100% every sprint is probably sandbagging estimates to guarantee an easy win, and a team consistently landing below 70% has a capacity or scoping problem that raw velocity will never reveal on its own. Watch accuracy first, and let velocity be a secondary, slower-moving trend line rather than the headline metric.
Plan sprints with capacity your team can actually trust
See how connected time tracking, attendance, and project planning give you a real capacity number before you commit.
Frequently asked
For a two-week sprint, aim for roughly one to two hours. Planning stays short when backlog grooming already happened beforehand, so the meeting is only about confirming capacity, agreeing the sprint goal, and committing to a set of already-estimated tickets rather than debating scope from scratch.
Backlog grooming (or refinement) is where tickets get written clearly, broken down, and estimated, usually in a separate session earlier in the sprint. Sprint planning is where the team takes that already-groomed backlog and decides what fits into the next sprint based on real capacity and a stated goal.
There's no universal number, it should match what the team has actually finished in recent sprints, adjusted for known absences, holidays, and time lost to support or client work. Committing to a number higher than recent historical throughput is the most common cause of sprints that consistently miss their plan.