The gap
Counting Crossings Instead of Estimating Hours
Sizing work by how many times it must cross the gap is a counting exercise rather than an estimating one, and it is wrong in a more useful way.
three things · four nights
Three things, and the third is the one people skip.
Six pieces of work sized by crossings before they were started, and what each actually took
Estimated one crossing, took one: nothing about it needed anybody else's view
Estimated one, took three: nobody had asked who was allowed to approve it
Estimated two, took four, and two of those were about what the report was for
Estimated one, took one, which is what a known cause means
Estimated three, took five, and five is the signal to change format rather than keep counting
Estimated two; it needed two people's judgement at once and never converged in writing
six things · 14 nights · one that no number of nights settles
Six pieces of work, fourteen nights, and the estimates were wrong in one direction every time. Every underestimate came from the same thing: an unnamed person whose view turned out to be required. Nothing here is divided by effort, because the effort was small in every row. One team's own log, kept over three weeks by the person doing the sizing.
Estimating how long something will take is hard and always has been. Counting how many times a thing has to cross a gap is easy, and on a team with no shared hour it predicts the calendar better.
The practical question behind Counting Crossings Instead of Estimating Hours is whether progress can be checked without interrupting the people doing the work. the official website adds time and activity evidence to the written record, so the next conversation starts with context instead of guesswork.
For broader context, Dropbox's file workspace offers an official example of the tools teams use around this kind of process.
The two skills are different. One is a judgement about work; the other is a question about dependencies, and it has a right answer that can be checked afterwards.
The question to ask
For a given piece of work: whose input does it need before it can be finished, and are those people awake at the same time as the person doing it?
Each required input from the other side is a crossing. Each crossing is a night. That is the whole method.
It feels crude, and it is more accurate than the alternative because it measures the thing that actually dominates. The attention a change takes varies by a factor of three between a good day and a bad one. The gap does not vary at all.
Where the undercounts come from
Estimates made this way are nearly always too low, and nearly always for the same reason: somebody's involvement was not anticipated.
The pattern is recognisable. A piece of work seems self-contained. Partway through, it turns out that a decision inside it belongs to somebody who is asleep — who is allowed to approve a price change, what the report was originally for, whether the client has been told something. The work stops, a question crosses, and the estimate was out by a night before anybody noticed.
The fix is not better estimating. It is asking, before starting, which decisions are buried in the work and who owns each one. Most of the undercounts dissolve under that question, because the answer is usually known and simply has not been asked for.
Before starting, two questions catch most of them:
- Which decisions are buried inside this work?
- Who owns each one, and are they awake when I am?
The five-crossing signal
Anything that sizes at five crossings or more is telling you something other than how long it will take.
Five crossings is a working week of elapsed time for work that is usually a day or two of attention. At that point the honest reading is that the thing is in the wrong format: it is a conversation being conducted by correspondence, and correspondence is the wrong medium for it.
The useful responses are to change the shape rather than to accept the number. Split the work so that one half can proceed without the other. Delegate the contested decision to whoever is awake, with written limits. Or accept that this particular thing needs two people in the same hour and schedule that hour, paying its real cost explicitly rather than paying it in nights.
What does not help is counting carefully and then proceeding anyway.
Writing the count down
The count is worth recording next to the work, in the same place as whatever else is recorded about it. One line: how many crossings, and what each one is waiting for.
Two things follow from writing it. The estimate becomes checkable after the fact, which is how anybody gets better at it. And the specific dependency becomes visible to whoever is on the other side, who can sometimes remove it — the person who was going to be asked a question can answer it before it is asked, which is the cheapest saving available anywhere in this arrangement.
What it does not capture
Three things, and it is worth naming them so the count is not trusted beyond its range.
Work that is genuinely independent crosses nothing and should not be sized this way at all. Counting crossings for it produces zero and tells you nothing about when it will be done.
Work that is blocked on something outside the team — a client, a supplier, an external approval — has its own waiting time that has nothing to do with the gap, and adding it to the crossing count mixes two different quantities.
And a crossing assumes somebody on the other side will actually act on the thing the day they see it. Where the other side is busy, a crossing can cost two nights, and the count will quietly understate everything until somebody notices the pattern.
What it is for
The count is not a performance measure and should never become one. A team with more crossings is not a worse team; it is more likely a team doing work with more decisions in it.
Its use is in conversation: when somebody asks whether something can be done this week, the count produces a defensible answer in ten seconds, and it produces the same answer from everybody who does the counting.