Here's a pattern I've seen play out dozens of times. A team estimates a feature at 5 story points. Low complexity, clear requirements, well-understood domain. By every estimation framework, it's a small task.
It ships three weeks later.
The team gets blamed for bad estimation. Leadership pushes for better grooming, more detailed breakdowns, tighter story points. The team tries harder. Next sprint, the same thing happens.
The estimate was never the problem.
Estimation does what it's supposed to do
Modern estimation frameworks are actually good at what they measure. The best ones decompose work into multiple dimensions: complexity (how hard is this to understand), effort (how much raw work), uncertainty (how many unknowns), and risk (what external factors could derail it). Each dimension gets scored, and the combination drives the story points.
This works. A 5-point story really is a 5-point story. The team correctly assessed the complexity of the code, the effort required, the technical unknowns. They weren't wrong.
The problem is that estimation measures the work. It was never designed to measure the environment the work has to travel through.
The gap has a name
Between "estimated" and "delivered" sits everything the estimation framework doesn't capture. I call it org friction: the invisible overhead that organizational structure, processes, and cross-team dependencies impose on every piece of work.
That 5-point story took three weeks not because the team misjudged the complexity. It took three weeks because a schema change needed approval from another team. The design review sat in a queue for days. Security wanted to sign off because it touches user data. The one person who understood the legacy service was unavailable. And the engineer doing the work got two focused hours per day between meetings, incidents, and "quick questions."
None of that is estimation error. It's organizational drag. And unlike technical debt, which at least gets mentioned in retros, org friction is untracked and unowned. It doesn't show up in Jira. Nobody has "reduce org friction" in their OKRs. But it's eating 30-40% of your team's capacity.
Seven sources of org friction
After paying attention to this for a while, I see the same patterns everywhere.
Cross-team dependencies. The work itself takes hours. The waiting takes days. Waiting for the Platform team to review your PR. Waiting for Design to finalize a spec they promised last sprint. The estimate captured the work. Nobody captured the queue time.
Process overhead. Change management boards, architecture review committees, compliance gates. Each one was created for a good reason. None of them were ever removed when the reason went away. They accumulate like sediment.
Knowledge silos. That one engineer who understands the billing service. That one PM who knows the historical context behind a weird product decision. When they're unavailable, work stops. Not because it's technically blocked, but because nobody else has the context to make the call.
Legacy process debt. This is different from technical debt. It's the outdated deployment process that requires manual steps. The testing pipeline that takes 45 minutes because nobody prioritized making it faster. The onboarding doc that hasn't been updated in two years. Not broken enough to fix, but slowing everything down.
Decision latency. No formal gate, just nobody with clear authority to make the call. Or the person who does keeps deferring. The feature is technically unblocked, but the team is waiting for someone to say "yes, build it this way." Estimates assume decisions happen instantly. They never do.
Context switching tax. The estimate assumed focused time. Reality: support rotations, incident responses, Slack threads from other teams, syncs that could have been async. The work takes three days of focused effort, but your engineers get two focused hours per day. The calendar is the friction nobody accounts for.
Misaligned incentives. Team A is measured on shipping features. Team B is measured on system stability. Team A needs Team B to deploy a breaking change. Team B has zero motivation to help. This isn't a technical problem. It's an organizational design problem. And it shows up as a "missed estimate" on Team A's board.
Stop improving estimation. Reduce the drag.
When teams consistently miss delivery targets, the default response is to push for better estimation. More grooming sessions. More detailed breakdowns. More precise story points.
This misses the point entirely.
The estimates are fine. A 5-point story is still a 5-point story. What changed between "estimated" and "delivered" wasn't the complexity of the work. It was the friction the work encountered on its way to production. Making teams better at predicting friction doesn't reduce it. It just makes everyone more accurately pessimistic.
The real lever is reducing the drag. And that's a leadership problem, not an engineering one.
Run a Friction Log
Here's the most useful thing I've done as an EM to make org friction visible.
For one sprint, ask your team to keep a shared doc. Call it a Friction Log. The rules are simple: every time someone is blocked, delayed, or slowed down by something that isn't the code itself, they log it. One line. What happened, how long they waited, which friction source it was.
No analysis during the sprint. Just logging. Keep it low effort.
After two weeks, read it together. What you'll see is a document that's almost impossible to argue with. Not opinions about process. Not complaints. Just a factual record of where time went that had nothing to do with the work your team estimated.
The first time I ran one, the log showed that 40% of the sprint's elapsed time was spent waiting on things outside the team's control. Cross-team reviews, decision latency, a compliance gate that took four days for a one-line config change. The estimates had been accurate. The org had been expensive.
A Friction Log does three things:
It separates estimation from delivery. You can see that the 5-point story really was a 5-point story. The extra two weeks was org friction, not estimation error. Once you can see the gap, you can talk about it.
It gives you data, not complaints. "Our estimates are always off" gets you a shrug. "Here's a log showing we spent 11 days this sprint waiting on cross-team reviews" gets you a conversation. Leaders respond to patterns with numbers.
It picks your battles for you. After one sprint, the top friction source is obvious. You don't have to fix everything. Pick the one that shows up the most and work on reducing it for the next quarter. Maybe it's getting embedded in the platform team's sprint review so your PRs don't sit in a queue. Maybe it's documenting the legacy service so you're not dependent on one person. Small, compounding improvements.
Nobody designed it this way
Nobody designed org friction into your company. It accumulated. One reasonable process at a time. One well-intentioned approval gate at a time. One team boundary at a time. Each decision made sense in isolation. Together, they created an invisible tax on every piece of work your team ships.
Your estimates aren't the problem. Your org is just more expensive than anyone's willing to admit.
The question isn't whether your team can estimate better. It's whether you, as a leader, are willing to name the drag and do something about it. Because the gap between "estimated" and "delivered" isn't a measurement error. It's a leadership opportunity.
Originally published on pixari.dev
Top comments (0)