The real cost of a broken handoff — and why it never shows up in your retrospective

The retrospective says: miscommunication. Misaligned expectations. Unclear requirements.

It never says: we spent 40 hours building the wrong version of a feature because the person who wrote the spec and the person who built it had different mental models of what “done” meant, and nobody caught it until QA.

That’s not a communication failure. That’s a coordination failure. The distinction matters because communication failures get fixed by talking more. Coordination failures get fixed by building better handoff infrastructure. Those are not the same solution, and applying the first to the second is one of the most expensive mistakes a product team can make.

What a handoff actually transfers

A handoff is supposed to transfer three things: the decision, the reasoning behind it, and the constraints it has to operate within.

Most handoffs transfer only the first. The spec says what to build. It rarely says why this and not that, what was considered and rejected, what the edge cases are and which ones matter, what the acceptable failure modes look like.

The engineer who receives that spec has to reconstruct the reasoning from incomplete evidence. Sometimes they get it right. Often they get it approximately right. Occasionally they get it wrong in a way that only surfaces three sprints later.

None of this appears in velocity metrics. The sprint moved fast. The features shipped. The rework gets absorbed into the next sprint as “polish” or “adjustments.” The cost is invisible because nobody measured the gap between what was intended and what was built.

The compounding problem

A single broken handoff is expensive but survivable. The problem is that broken handoffs compound.

Each feature built on incomplete context creates a slightly wrong foundation. The next feature is built on top of that. By the time you’re six months in, you have a codebase and a product that diverges from the original design intent in small, individually reasonable ways that collectively amount to something nobody actually decided to build.

This is product drift. It doesn’t announce itself. It accumulates.

The diagnostic question isn’t “do our specs need to be more detailed?” It’s “does the person building the thing have access to the same model of the problem as the person who defined it?” If the answer is no — and in most teams it’s no — more detailed specs don’t fix the problem. They add overhead to the wrong solution.

What the fix actually looks like

The fix is structural. It requires that the reasoning behind decisions be stored somewhere accessible, not just in the memory of the person who made them. It requires that the handoff be designed as a transfer of context, not just a transfer of instructions.

This is the problem I work on with teams. Not the symptoms — the late sprints, the rework, the misaligned features — but the underlying coordination model that produces them. The symptoms are consistent. The root cause is almost always the same: knowledge is concentrated in people instead of structured in systems.

The Clarity Sprint is how I start. Five days. No deliverables on day one. Just a rigorous diagnosis of where the knowledge actually lives and where the gaps are.

Read about the Clarity Sprint