Sprint Planning Is Blocked. Everyone Is Waiting for the One Person Who Knows.

The story has been in the backlog for three sprints. Every time it comes up in planning, the same thing happens: the team can't estimate it because the one person who understands the notification service isn't available to give context. So it gets deprioritized again. The work is not blocked by technical complexity. It's not blocked by capacity. It's blocked by the fact that estimating it requires knowledge that only one person has, and that person is on PTO, or in a critical meeting, or leading onboarding this week.

This is the sprint planning version of the tribal knowledge problem — and it's one of the least visible costs of knowledge concentration. The story doesn't fail. It doesn't create an incident. It just moves right, sprint after sprint, accumulating calendar time without consuming any engineering time. The feature that should have shipped in Q3 ships in Q4 or not at all, and the root cause is that one engineer's availability was the prerequisite for the team's ability to even begin.

Estimation as a knowledge problem

Good sprint estimation requires understanding the work. Understanding the work requires system context. System context for unfamiliar services currently requires the person who built or maintains them. This chain is so normalized that most teams don't notice it as a dysfunction — they just treat "waiting for Marcus" as a planning constraint, the same way they'd treat "waiting for QA capacity."

But the two constraints are different in kind. QA capacity is a resource constraint — adding capacity requires headcount. Knowledge availability is an access constraint — the information exists, it's just locked in one person's head. Resource constraints require investment to remove. Access constraints require distribution to remove. They call for different fixes.

The same story, three sprints in a row:

  Sprint 14: "Notification service refactor — 8 points"
    Status: Deprioritized. Marcus is OOO. Can't estimate without him.

  Sprint 15: "Notification service refactor — 8 points"
    Status: Deprioritized. Marcus is leading onboarding for new hires.

  Sprint 16: "Notification service refactor — 8 points"
    Status: Deprioritized. Marcus added to the incident channel this week.

  Sprint 17: "Notification service refactor — ?"
    Marcus is back. Estimation takes 90 minutes. Story begins.

  Calendar time elapsed: 8 weeks. Engineering time spent: 0 minutes.
  Root cause: estimation required someone who had the context.

What stories need to be estimable

Most estimation blockers are answerable questions: what does this service currently do, what are its dependencies, where are the fragile areas, what's the test coverage, what changed recently. These questions have answers in the codebase. They require access to the codebase to answer, not Marcus's presence in the planning meeting.

When any engineer on the team can ask "what does the notification service do and what would a refactor need to touch?" and get a navigable answer from the codebase, the dependency on Marcus for estimation disappears. The 90-minute context-sharing session becomes a 10-minute codebase query. The story moves into the sprint without waiting for Marcus's availability.

What the team needs to estimate a story involving an unfamiliar service:
  -> What does the service currently do?
  -> What are the external dependencies?
  -> What's the data model?
  -> Are there known edge cases or fragile areas?
  -> What changed recently that might affect the refactor?
  -> What's the test coverage?
  -> Who would need to review changes?

  All answerable from the codebase.
  Currently answerable only by Marcus.

The compounding cost of blocked stories

A story that moves right by one sprint has real costs: delayed features, misaligned roadmap commitments, accumulated technical debt, and reduced team morale as engineers watch work stack up while they're blocked on a knowledge access problem. A story that moves right for three sprints due to the same cause represents a planning process failure worth diagnosing.

Teams that track "reasons for story deferral" often find that single-person knowledge dependencies are among the top causes — but they're categorized as "resource unavailability" rather than "knowledge access," which makes them look like scheduling problems rather than structural ones.

Kognita as the estimation unlocker

When the team can query the codebase before planning, stories involving unfamiliar services become estimable without their original authors present. Engineers query service boundaries, dependencies, recent changes, and complexity indicators from the live index. Marcus's context is still valuable for nuance — but it's no longer required to begin estimation. The sprint moves forward when Marcus is on PTO, in an incident, or onboarding new hires.

Final take

Stories blocked on knowledge availability aren't blocked by capacity or complexity. They're blocked by access. The codebase contains most of what estimation needs. Making that accessible to the team turns a knowledge bottleneck into a two-minute query and a story that ships in the sprint it was planned for.

Stories don't get blocked by Marcus being unavailable. They get blocked by the team not having access to what Marcus knows. The codebase has most of that. Make it accessible and Marcus stops being a prerequisite.