The Velocity Blindspot — Why Healthy-Looking Sprints Still Slip
Your board tracks tickets. It doesn't track who was at their desk. That gap is why your forecasts keep missing, and you can close it without another brittle integration.
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 were all staring at a clean dashboard trying to reconstruct what happened. Nobody had slacked off. The work just hadn't added up to the outcome.
The variable the board can't see is the one that quietly decided everything: who was actually available to do the work.
A sprint board assumes the whole team was equally present every day of the iteration. They almost never were. Someone was on pre-approved leave. Someone else had standing focus blocks for a migration. One office had a public holiday the others didn't. Two engineers were carrying on-call. 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 move is to wire your HR system into your dev tools so the board knows who's out. Anyone who's tried it knows how that 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. These integrations are a maintenance tax, and it always seems to come due in the middle of a release.
So most teams just don't. 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 as the Model Context Protocol spread. Instead of hard-wiring systems together, you let an AI client query each one on its own and reason across them in a single pass: Jira, the Git repo and an availability server at once, in service of one question.
Here's what that looks like in practice. 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 actually 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; 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 heading 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 start resting on real human capacity instead of an idealized roster. Retros get kinder, because the honest explanation is usually "we had fewer people than the plan assumed," not "people underperformed." And you commit to dates you can actually staff.
That's what we're building at SquadBear: team availability your AI tooling can read as easily as it reads a Git log, so the next forecast knows who's at their desk before it promises anyone a date.
Try it on your team
Point your AI client at the SquadBear demo and have it fold your team's real availability — leave, public holidays, focus blocks — into the next sprint forecast. 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.