The Velocity Blindspot: Why Healthy Sprints Still Slip

Photo: Pavel Danilyuk / Pexels

I've sat through this retro more times than I'd like to admit. The sprint looked fine going in: tidy board, sensible estimates, a burndown that behaved for the first few days. Then the date slipped anyway, and we all stared at a clean dashboard trying to reconstruct what happened. Nobody had slacked off. The work just hadn't added up to the outcome.

What the board couldn't show us was the thing that decided the sprint: who was actually available to do the work.

A sprint board assumes the whole team is equally present every day of the iteration. They almost never are. Someone was on approved leave. One office had a public holiday the others didn't. Two engineers were carrying on-call, and a third had blocked half her calendar for a migration. None of that sits next to the story points, so the plan was built on a headcount that didn't exist on the days it mattered.

Why this is so annoying to fix

The obvious fix is wiring your HR system into your dev tools so the board knows who's out. If you've tried it, you know how it ends. You build a custom bridge between a legacy HR platform and Jira, it holds for a quarter, then the vendor changes an API or the person who built it leaves, and now there's a broken pipeline nobody wants to own. That maintenance tax always seems to come due in the middle of a release.

So most teams don't bother. They plan as if everyone is always there, and they pay for it in the retro.

A different way to ask the question

This got a lot more practical once the Model Context Protocol spread. Instead of hard-wiring systems together, you let an AI client query each one on its own: Jira, the Git repo, and an availability server, all in service of a single question. You ask:

"Cycle time on the payments service jumped about 60% last sprint. Cross-reference the merged and stalled PRs, the ticket transitions, and team availability for those two weeks, and tell me the most likely explanation."

And instead of a shrug, you get something you can use:

"The PRs didn't stall on review quality; review turnaround was normal. Two of the five backend engineers were on pre-approved leave for part of the sprint, and a third had standing focus blocks for the Q3 migration. Effective backend capacity was closer to 55% of nominal. The cycle-time increase tracks that capacity dip, not a process breakdown."

The data was always there. What was missing was anything that could hold all three sources side by side at the moment you asked.

One honest caveat: this is decision support, not a crystal ball. It points you at the likely story, and it won't replace talking to your team. But getting pointed at the right question is most of the value. It turns a retro that was drifting toward a blame hunt into one that ends with "right, half the team was legitimately out, let's plan the next sprint around who's here."

What you get on the other side

Forecasts that rest on real human capacity instead of an idealized roster. Retros get kinder too, because the honest explanation is usually "we had fewer people than the plan assumed" rather than "people underperformed."

That's what we're building at SquadBear: team availability your AI tooling can read as easily as it reads a Git log. The agent connects over MCP and acts with your own permissions, so it sees what you're allowed to see and nothing more.

Try it on your team

Point your AI client at the SquadBear demo, then hand it something real:

"Fold the team's actual availability (leave, public holidays) into the next sprint forecast and tell me what capacity we really have."

When it earns its keep, start free and bring it into your planning.

Next in this series: your AI summary shouldn't require a copy of everything, on the privacy story underneath all of this.