The short version
- Work waits for people to be free. On a distributed team that waiting is measured in nights, and it does not appear on any board.
- Estimates cover the working. The slippage comes from the waiting between the working, which nobody estimates.
- Measure elapsed time against active time on five completed items. The gap is your real delivery problem.
- Most of the waiting is for answers rather than for decisions, and answers do not need a person to be awake.
Distributed projects slip for a reason that is almost never in the retro. The team did not work slowly. The work spent most of its life not being worked on at all, waiting for a person to become available, and nobody counted that time because no system records it.
"Work waits for people to be free."
Work waits for people to be free
Follow one ticket from start to finish and the shape becomes obvious. Two hours of work, then a day waiting for a clarification. Three hours of work, then two days waiting for a review. Thirty minutes of changes, then a day waiting for a decision about scope.
Seven hours of work spread over five days. The engineer was busy the whole time, on other things, so nobody experienced idleness. The item was idle for eighty percent of its life, and the board showed it as in progress throughout.
Across time zones each wait has a floor of one night, because a question asked after the other zone logs off cannot be answered sooner. That floor is what turns ordinary coordination into slippage.
Why estimates keep missing it
Estimates answer a question about effort: how long will this take to do. That question is usually answered reasonably well, and it is the wrong question for a distributed team.
The question that predicts delivery is how long this will take to get through, which includes every handoff, every clarification, and every review. Teams add a multiplier to cover it, which is a way of budgeting for the waiting without examining it, and the multiplier grows every quarter because the underlying cause is untouched.
Measure elapsed against active
Take five recently completed items. For each, record two numbers: elapsed time from start to done, and your honest estimate of hours actually spent on it.
| Ratio of elapsed to active | What it means |
|---|---|
| Under 2 to 1 | Healthy. Your constraint is capacity, not coordination |
| 3 to 1 | Normal for a distributed team, and worth attacking |
| 5 to 1 or worse | Waiting is your delivery problem. Hiring will not help |
The last row is worth dwelling on. Adding people to a team with a 5 to 1 ratio adds more waiting, because each new person creates more handoffs. It is the most common expensive response to a coordination problem.
Four kinds of waiting
Sort the waits you found, because they have different fixes.
- Waiting for an answer. Usually the largest. Someone needs to know something that already exists, and the only route is a person.
- Waiting for a decision. Genuine, and reducible by moving authority closer to the work, as in the DRI model.
- Waiting for review. Reducible with review commitments and smaller changes.
- Waiting for a dependency. Real work by another team. The only honest fix is sequencing.
Removing the largest kind
The first category is the one that does not have to exist. The answer exists; what is missing is a route to it that does not require a specific person to be awake.
With StandIn, each person confirms a ninety-second brief at the end of their day, mostly pre-drafted from the work they already did: current state, open questions, blockers, next actions, decisions and why. While they are off, their StandIn answers questions from that brief in their words, with a source under every answer, clearly labelled, and it never guesses. When the answer is not there, it says so and names who to ask, which means the engineer knows within seconds whether this one really does have to wait a night.
Run the elapsed-to-active measurement again a month later. The ratio is the number that tells you whether the waiting actually fell, and it is a better measure of a distributed team's health than velocity is. See StandIn for leadership teams.
Common Questions
Why do distributed projects slip more than co-located ones?
Because every handoff has a floor of one night. The work takes the same time; the waiting between the work is multiplied by the number of seams the item has to cross.
Will adding people help?
Not if your elapsed-to-active ratio is high. More people means more handoffs, and handoffs are where the time is going. Fix the waiting first, then judge whether capacity is the constraint.
How do we measure waiting?
Take five completed items and compare elapsed time with hours actually spent. The ratio is a more useful number than velocity, because it distinguishes a capacity problem from a coordination one.
Is some waiting unavoidable?
Yes. Genuine decisions need the person who holds the authority, and real dependencies need the other team to finish. What is avoidable is waiting for information that already exists, and that is usually the largest share.
When you're off, your StandIn is on.
It answers your teammates' questions from work you've already done, in your words, with a source under every answer.