How We Plan Our Work Every Week, the Simple Way

Sprint planning theater looks like progress — story points assigned, a burndown chart trending down, a velocity number that looks consistent quarter over quarter. None of that tells you whether the team is unblocked.

We plan around dependencies first: what's blocked, on whom, and since when. Estimates come second, and only for work that's actually scoped enough to estimate.

The single biggest change was making blockers visible daily instead of surfaced only in retro. A blocker that sits for three days before anyone says it out loud costs more than a bad estimate ever will.

Velocity is the most misleading number in software planning, because it's easy to compute and easy to game without anyone deciding to game it. A team under pressure to hit a target naturally starts sizing tickets slightly larger, or splitting work into more tickets than it needs, and the chart keeps trending the right direction while the actual throughput stays flat. We track velocity, but we don't plan around it — it's a lagging indicator, not a lever.

Planning around dependencies instead of estimates changes the shape of the meeting entirely. Instead of asking 'how many points is this,' we ask 'what does this need before it can start, and do we have that yet.' A ticket that's fully scoped, unblocked, and ready to go gets estimated. A ticket that's waiting on a design decision, an API contract, or another team's output gets flagged as blocked and left out of the sprint commitment, no matter how important it is.

This surfaces a different kind of problem than a burndown chart does. A team can be burning down story points on schedule while the one ticket that actually matters to the client sits blocked the entire sprint, invisible in the chart because nobody assigned it points yet. Tracking blockers explicitly, as their own list with an owner and an age, makes that invisible problem visible on day one instead of in the sprint retro two weeks later.

Age is the detail that makes the blocker list actually useful instead of just another list. A blocker that's one day old is normal — someone's waiting on a Slack reply. A blocker that's four days old is a planning failure that needs an actual conversation, not another day of waiting. We review blocker age daily, not weekly, because the cost of a stuck ticket compounds every day nobody addresses it.

We still estimate, because a client or a stakeholder reasonably wants some sense of when something will ship. But we estimate confidently only on work that's already unblocked, and we say 'not yet estimable' out loud for everything else instead of guessing to fill in a number. A wrong estimate erodes trust faster than an honest 'we don't know yet.'

The version of sprint planning that actually predicts delivery isn't the one with the most precise-looking chart. It's the one where everyone in the room knows, at any moment, exactly what's stuck and why.