From backlog to done: planning a sprint that actually finishes

Every team has run the sprint that started full of optimism and ended with half the board still in progress. You pulled in everything that felt important, the first few days went fine, and then reality showed up: a production bug, a sick day, an estimate that was wildly wrong. The sprint didn't fail because anyone was lazy. It failed at planning, before a single line of code was written.

The fix isn't working harder. It's committing to the right amount in the first place, then defending that commitment. Here's how we plan sprints that finish.

Start with what you actually did, not what you hope to do

Optimism is the enemy of a finished sprint. The antidote is data. Look at your last three or four sprints and ask a blunt question: how much did the team reliably complete, not on the best week, but on an average one?

That number is your velocity, and WannaTrack surfaces it right in the planner as you pull work in. When your committed total starts creeping past your average, the planner shows it, so over-committing becomes a choice you can see instead of a mistake you discover in week two.

A good rule when you're not sure: plan to about 80 percent of your average velocity. The missing 20 percent is not slack. It's the space real weeks need for the interruptions you can't predict.

Order the backlog ruthlessly

A backlog isn't a wishlist. It's a queue. The item at the top should always be the next most valuable thing to build, and everything below it should be in honest priority order.

When two items fight for the top slot, one of them isn't actually next. Break the tie deliberately:

• Value: which one moves the needle for a user or the business?
• Risk: which one, if it turns out to be hard, do you want to learn about early rather than late?
• Dependency: does something else need this done first?

Ordering is uncomfortable because it forces you to say one thing matters more than another. Do it anyway. A backlog where everything is "high priority" is a backlog with no priority at all.

Size the work before you commit to it

You can't plan the right amount if you don't know how big the pieces are. Size the top of the backlog together before the sprint, not during it. Run planning poker right in WannaTrack so the whole team estimates at once and the outliers surface a conversation ("why did you say 8 when I said 2?") that usually reveals a hidden assumption.

If an item is too big to estimate with confidence, that's your signal to split it. A story you can't size is a story you don't understand yet, and shipping half of something understood beats shipping none of something vague.

Leave room for the work you didn't plan

Bugs happen. Support escalations happen. If your team carries a steady load of unplanned work every sprint, stop pretending it won't happen this time. Reserve capacity for it up front. A sprint that plans for reality finishes. A sprint that plans for a perfect week doesn't.

Make "done" mean done

The fastest way to a lying board is a fuzzy definition of done. Nail it down:

• Acceptance criteria on the ticket, written before the work starts, so "finished" isn't a matter of opinion.
• A definition of done the whole team agrees on: tested, reviewed, merged, whatever your bar is. The same bar for everyone.
• A status that only moves when both are met. "Done" is not "done on my machine." If it isn't really done, the board shouldn't say it is.

When done means done, your burndown tells the truth, your velocity becomes trustworthy, and next sprint's plan gets sharper. It compounds.

Protect the sprint once it starts

Planning well is wasted if you undo it on day three. When new work appears mid-sprint, the default answer is "next sprint," not "just squeeze it in." If something is genuinely urgent enough to break that rule, then something else comes out to make room. Scope traded, not scope piled on. The sprint goal is a promise, and finishing is a habit built one protected sprint at a time.

Close the loop

At the end, read the burndown honestly and run a short retro while it's fresh. Did you finish? If not, was it the estimate, the interruptions, or the plan? Feed that answer into next sprint. This is the whole game: plan less than you fear, finish what you planned, and let the velocity report prove it out over time.

Plan less. Finish more. Then do it again.