Your sprint did not slip because of bad estimates

The pattern is familiar. Stories come in, the senior engineer nods, the team poker-plans a sprint, and by Friday of the second week roughly a third of the work has crossed into the next sprint. Again. The retro lands on the same diagnosis: bad estimates.

It is rarely the estimates. It is usually that nobody saw who else was going to touch the same files.

Sprint rollover and forecast miss are often symptoms of dependency-coordination mismatch, not poor estimation discipline. Fixing that is delivery-system work. It is not Conway's Law, and the prescription is not more Planning Poker.

What the survey says

Easy Agile's late-2025 survey of 419 engineers, PMs, and project managers across five countries reports that 80% of teams routinely roll planned work into the next sprint. About a third roll 26 to 50% forward. The top stated cause is dependency delays at 36%. Estimation ranks lower than most readers would guess.

The same survey says 63% of teams call their estimates "very" or "extremely" confident. On those same teams, 44% say roughly half their work or more ends up significantly larger or smaller than estimated. Both are true for the same people. That gap is the post.

Caveat: Easy Agile sells alignment tooling, so their survey will find teams need more alignment tooling. Treat it as a sentiment thermometer, not mechanism. For mechanism, go back almost twenty years.

What Cataldo, Herbsleb and Carley actually showed

In 2008, Cataldo, Herbsleb and Carley published Socio-Technical Congruence: A Framework for Assessing the Impact of Technical and Work Dependencies on Software Development Productivity. It is still one of the better empirical anchors for what happens when teams and dependencies misalign.

They watched a large distributed product for 39 months: 114 developers, 8 teams, 3 sites, 2,375 multi-team modification requests. For each, they reconstructed who actually coordinated and who needed to, then regressed against resolution time.

When coordination patterns matched dependency-driven needs, average resolution time fell by roughly 32%. One context. The direction matters more than the exact number.

The more useful finding is methodological. They compared two ways of identifying dependencies: syntactic call/data relationships, and logical dependencies, meaning files changed together for the same modification request. Logical dependencies were a much better predictor of who needed to coordinate. Syntactic ones, the kind any engineer can see, often missed the real coordination structure.

The dependencies your engineers can see are not the dependencies that drive the queues.

Why this looks like an estimation problem

Ask a senior engineer how long a change will take. She thinks about the files she will touch, the modules involved, the people she knows she will need. The estimate is almost always optimistic. Not because she is lazy, but because dependencies invisible from the code are underweighted.

The work hits the sprint. Day three: another team notices a file they own was changed and pushes back. Day eight: deployment is blocked because an upstream API contract was implicitly changed. Each missed coordination event adds rework. Rework adds variability.

Reinertsen's flow economics gives the queueing logic: queues at high utilization are not linear; small variance produces large average wait. Sprints run hot by design, so dependency mismatch adds variance the queueing math punishes disproportionately. The team calls this "we keep underestimating." The system is producing exactly the variance its structure predicts.

This is not Conway's Law. Conway is about how org structure shapes architecture. Congruence asks a different question: given your current architecture and current org, do communication patterns match the dependencies that exist right now? You can have a sensible org chart and still be congruence-broken, because the real coupling lives in logical dependencies no diagram shows.

The honest version of "agile fixes this"

Agile rituals do not fix dependency mismatch. They sometimes expose it. A Planning Poker moment where a senior engineer says "wait, this touches the auth module, we need Anna" is congruence in real time. It works when overlap and psychological safety make the callout cheap. It fails when the dependency lives outside the team's awareness, which Cataldo et al. show is common once a system gets past a certain size.

Scrum-of-Scrums, PI Planning, and dependency boards coordinate the dependencies someone thought to put on the board, not the ones that fire. The work that slips is the work nobody put on a sticky.

The fix is to make the hidden structure visible before the work hits the sprint.

Something you can do on Monday

Three steps. None require new tooling.

• Pull a co-change report. From version control, for the last six months, list pairs of files changed together more than a small threshold of times. Most teams already have this; nobody looks at it. That is your logical dependency graph.
• Overlay it on team boundaries. Highlight co-change pairs that cross team lines. Those crossings are where your hidden coordination tax lives.
• Pick one crossing and design a routine, not a meeting. The worst offender gets a clear trigger (when a change touches this set), a clear input (what the changer must share), a clear decision (what the other side must do or escalate), a clear exit. Run it for four weeks. Measure cycle time and rework on that surface.

The temptation will be to redesign team boundaries. Sometimes that is right. More often, the cheaper move is to leave the boundary alone and design coordination across it. Boundaries are expensive to move. Routines are cheap to install.

A question I would not skip

Before any of this, ask the team one question: of the work that rolled over last sprint, how often did it share an upstream contributor or file with another team's work? If the answer is "we don't know," you have diagnosed the problem without writing a line of code. The inability to answer is the finding.

The system is telling you, in the dullest possible voice, that its coordination structure is opaque to the people inside it. That opacity is not solved by another retrospective. It is solved by treating coordination as a design variable, the same way you treat architecture.

The team probably has enough discipline. The system has the wrong wiring.

Sources

• Cataldo, M., Herbsleb, J. D., & Carley, K. M. (2008). Socio-technical congruence: A framework for assessing the impact of technical and work dependencies on software development productivity. In Proceedings of the Second ACM-IEEE International Symposium on Empirical Software Engineering and Measurement (ESEM '08). ACM. doi.org/10.1145/1414004.1414008
• Easy Agile. (2026, February 12). State of team alignment 2026. easyagile.com/blog/agile-predictions-insights-2026-team-collaboration-research
• Rajapakse, R. N., & Szabo, C. (2025). Towards multi-class socio-technical congruence: Assessing coordination in collaborative software development settings. Journal of Software: Evolution and Process, 37(9), Article e70040. doi.org/10.1002/smr.70040
• Reinertsen, D. G. (2009). The principles of product development flow: Second generation lean product development. Celeritas Publishing. search.worldcat.org/title/435994279