The Profit Your Sprint Plan Already Spent
Your Plan Failed Before the Sprint Started (Profit With Proof | Episode 6)
The Ghost Capacity Trap
Your resourcing model says you have time. Your engineers know otherwise.
👋 Welcome to this week’s edition of Empathy Engine. Every Wednesday (formerly Tuesday), I publish a new article for paid subscribers first, then unlock the full piece for everyone late Thursday morning. Each week, I turn product leadership friction into practical tools, sharper language, and more defensible decisions.
I have watched a resourcing spreadsheet turn a drowning team into a neat green row while the “20% available” column quietly ignored support rotation, code review, production noise, and the one senior engineer every urgent question somehow found first. Everyone could see the number was wrong, but nobody wanted to be the first person to make the meeting uncomfortable.
A resourcing manager prepares a capacity plan for the next quarter. Four engineering teams. 80% allocated. 20% available for new work. The spreadsheet looks responsible. The numbers are clean. Three engineering leads review the plan and ask the same question: “available to whom?”
The 20% represents time that exists on paper between scheduled deliverables. It does not account for context switching costs, interrupt-driven support requests, code review obligations, documentation debt, or the undocumented work that fills every gap the plan does not acknowledge. The capacity is real in the spreadsheet. It is ghost capacity in the building.
That is the Ghost Capacity Trap!
The plan looked clean because the system only counts the work that made it onto the board. Here is what happens to that plan by Wednesday.
The Rework Tax priced work paid for twice. The Escalation Delay Cost priced the silence between warning and owner. The Integration Penalty priced the workaround nobody removed. The Agile Meeting Burn Rate priced coordination that lost its return. Each of those costs was survivable. That is the trap. Ghost capacity is the operating condition that made every one of those costs absorbable long enough to ignore.
Research Binder: the receipts (citations + source notes) are compiled in a PDF at the bottom of this article.
What this article does and does not claim
Does: give you a defensible way to estimate your own ghost capacity exposure, and a diagnostic structure you can carry into a capacity planning conversation.
Does not: claim a universal benchmark for invisible work, guaranteed capacity recovery, or a specific percentage that applies to your team without measurement.
If you are skimming
Read three sections: You start the sprint with less than you think, The spreadsheet shows green, and What leaders should do next. The Capacity Reality Check sits between them as the operational payoff.
TL;DR
Ghost capacity is the gap between what the resourcing model says is available and what the team can actually direct to new work.
Most capacity models measure allocation, not availability. The gap between them is where burnout accumulates and delivery commitments quietly become unrealistic.
The system does not just fail to measure invisible work. It rewards absorbing it silently and punishes naming it openly.
The Capacity Reality Check turns that gap into a number your leadership team can challenge in a QBR.
You start the sprint with less than you think
Capacity planning feels reliable because the system produces a specific number. The number is clean. It reconciles with the headcount. It maps to the sprint. It looks like something you can commit against.
The number is also structurally incomplete.
The CISQ 2022 Cost of Poor Software Quality report, aggregated from 88 US public sources, estimates that roughly 33% of developer time is consumed by unplanned work and rework. For a 10-person team that appears to have 10 developer-days available, true starting capacity is closer to 6.7. The missing 3.3 developer-days are not a rounding error. They are a structural misread of reality that the plan never accounts for, because the plan was not designed to see work the system does not formally track.
When that missing capacity inevitably surfaces mid-sprint, it looks like disruption. It is not. It is a delayed reveal of time that was already spoken for before the sprint began.
Here is what the capacity plan reports.
Here is what the team actually starts with.
The missing 3.3 developer-days do not vanish randomly. They follow consistent, repeatable channels that show up across teams. Context switching imposes a recovery tax: each interruption costs an average of twenty-three minutes of cognitive reorientation before deep work resumes. Unplanned requests arrive through side channels (ie. Slack pings and “quick favors” that bypass the sprint board entirely). Technical debt accumulates as a permanent, undocumented capacity tax. Meeting overhead consumes executable hours. Recovery overhead compounds the cost of every interruption beyond its visible duration. Additionally, knowledge concentration routes critical decisions through one person, creating a single-point-of-failure that quietly absorbs capacity nobody budgeted. Yeah! It’s a lot.
The plan did not lie. It had no place to put the truth.
Six categories of invisible work consume capacity before commitments are made. None of them appear on the sprint board.
The system trains teams to overcommit
The most dangerous part is not the extra work. It is what the organization learns from watching the team survive it. When teams successfully “handle it,” the organization quietly updates its expectation of what that team can do. Over time, invisible effort becomes normalized capacity, and overcommitment stops looking like a problem and starts looking like performance.
When absorption looks like performance, the trap has already closed.
The sprint starts clean. New work enters informally. Nothing is removed from the original plan. The team absorbs the additional load without updating the commitment. The next sprint then starts from the same unrealistic baseline, because the previous sprint appeared to succeed. The illusion reinforces itself. Each cycle raises the organization’s expectation of what the team can carry, because the team kept carrying it. The fact that they carried it through overtime, cut corners, and quiet exhaustion does not appear in any system the planning process consults.
This is another broken route, but the one running between what the spreadsheet reports and what the team actually experiences.
Invisible work is not disruption. It is the operating system. The system fails to account for it because accounting for it would make the plan less comfortable to present, and the meeting rewards comfortable plans.
The loop has a shape. It repeats every sprint, and it starts from the same false baseline each time.
