Better Estimates From Your Team’s Own Logged Time
Estimates run late because they’re built from the plan, not from what happened last time. Use your team’s logged time to estimate in ranges, and keep it honest by never using it to rank people.
Jordan estimates the client site migration at six hours. It takes eleven. Jordan isn’t careless, and the next estimate won’t be better just because you mention it. The problem isn’t effort. It’s where the estimate came from.
Most estimates are built by imagining the work: list the steps, guess each one, add them up. That method leaves out everything that usually goes wrong, because nobody plans for the client’s missing login. On a remote team, where an overrun can sit unnoticed for days, bad estimates are expensive. This guide covers a better source: the time your team has already logged.
Why estimates run late
Psychologists call it the planning fallacy. In a 1994 study, Buehler, Griffin and Ross asked 37 students when they’d finish their honors thesis. The average estimate was 33.9 days. The average actual time was 55.5 days, and only about 30% finished within the time they predicted. The students also gave a worst-case estimate, “if everything went as poorly as it possibly could.” That averaged 48.6 days, still a week short of what actually happened.
That last number is the useful one. Asking people to think harder about what could go wrong doesn’t fix the estimate, because they’re still reasoning from the plan.
Use your team’s history, not the plan
The fix is to look outward instead of inward. Reference class forecasting, which Bent Flyvbjerg developed for large projects from Kahneman and Tversky’s work, bases a forecast on the actual outcomes of similar past projects rather than on the plan for this one. It was built for bridges and rail lines, but the idea works at the scale of a task.
Your team already has the best reference class you’ll find: how long similar work took when these people did it, for these clients, with these tools. If people log their time on the task they’re working on, every finished task adds a data point. After a month, you’ll have enough history for your common kinds of work.
How to build your reference classes
A reference class is a group of tasks similar enough to compare. Get it right and estimates improve quickly. Get it wrong and the history is noise.
- Group by kind of work, not by client. “Client onboarding”, “landing page”, “monthly report”. Client differences show up as a wider range, which is useful in itself.
- Use the last ten to twenty. Older history reflects old tools and different people. Fewer than five isn’t a pattern yet, so set an appetite instead.
- Split when the range is wide. If “landing page” runs from two hours to two days, it’s really two kinds of work. Name them separately.
- Keep the unit stable. If a task sometimes includes review and sometimes doesn’t, logged time will wander. Decide what the card covers, and keep it that way.
Keep the logged data clean enough to use
Estimates from logged time are only as good as the logs. Three habits keep them useful without turning time tracking into a chore:
- Log to the task, not the day. Time that isn’t attached to a task can’t inform the next estimate.
- Tag the type of work. “Client onboarding” and “bug fix” need different reference classes.
- Note what was unusual. A one-line note such as “waited two days for content” explains an outlier, so you can decide whether to keep it.
Estimate in ranges
A single number hides how much similar work varies. Give two instead:
- Typical: the middle of your history. Half of similar tasks took less, half took more. Plan the week with this one.
- Most within: the time that eight out of ten similar tasks finished within. Make promises to clients and other teams with this one.
The gap between the two is information, not noise. When it’s wide, the work isn’t well understood yet, and that’s worth knowing before you commit to a date.
A worked example
Priya’s team sets up new client accounts. The checklist says three hours. Their last ten logged onboardings took 3.5, 4, 4, 4.5, 5, 5, 5.5, 6, 7.5 and 9 hours. The typical time is five hours, and eight of the ten finished within six. So Priya plans five hours a week per new client and tells sales to promise setup within six working hours. The two-hour gap between the checklist and the typical time is the planning fallacy, measured in her own team’s data.
Separate working time from waiting time
A task with five logged hours can take four days from start to finish, because it waited: for a client, for a review, for someone in another time zone to wake up. Most work that’s “late” on a remote team is late because of waiting, not working. Asking people to work faster won’t help.
Track both. Logged time tells you how much effort a kind of work takes. Elapsed time tells you how long it sits in queues. If elapsed time is the problem, fix the handoffs, the review windows and the questions that start an overnight round trip.
For new work, set an appetite instead
When there’s no history, don’t pretend there is. Basecamp’s Shape Up method offers a better tool: an appetite, the amount of time the work is worth. As the book puts it, “Estimates start with a design and end with a number. Appetites start with a number and end with a design.”
In practice, it sounds like this: “This is worth about four hours. If it’s heading past that, stop and tell me what you’d cut.” Fixed time, variable scope. The person still has room to judge, and you find out at four hours instead of fourteen.
Log time to learn, not to police
Here’s the part that makes all of this work: never use logged time to rank people. The moment logs are used to judge someone, people pad them, round them or stop logging the hard parts, and your history stops being true.
Compare kinds of work, not people. Let each person see their own estimates against their own logged time, privately. Look at categories as a manager: which kinds of work keep overrunning, and why. When a task runs long, the question is what the estimate missed, not who was slow.
Be suspicious of estimates that are always right
A person whose tasks always finish exactly on the estimate isn’t necessarily a great estimator. Work tends to expand to fill the time it’s given, and a generous estimate quietly becomes the actual. Real work varies. If someone’s logged time never lands under the estimate, the estimates are probably padded, and the padding is hiding how long the work really takes.
Don’t treat it as dishonesty. Padding is a rational response to being judged on overruns. Tell people that a task finishing early is good news, that overruns are information rather than failures, and that the range exists so nobody has to pad. Then show it: the first time someone finishes early and picks up the next card, say so.
Recalibrate once a month
Once a month, look at the kinds of work where logged time was furthest from the estimate. Update the typical and most-within numbers, and ask whether the work itself changed: a new client, a new tool, a step that got added. Ten minutes a month keeps the history current without turning it into a project.
Common estimating mistakes
- Treating the estimate as a deadline. An estimate says how long the work usually takes. A deadline says when it’s needed. Mixing them up is how padding starts.
- Re-estimating mid-task to look accurate. If a task is running long, leave the original estimate and flag the overrun. Changing the estimate erases the record of what was missed.
- Comparing new people with the team on day one. Someone in their first month will run slower on unfamiliar work. Let their own history build before comparing it with anyone’s.
- Estimating alone. The person doing the work usually knows something the planner doesn’t. Start from the history, then ask them what’s different this time.
Share ranges with clients and stakeholders
Ranges only help if people outside the team understand them. When you give a client or another team a date, give them the promise number, the time most similar work finishes within, and say what would push it later. “Setup takes five hours of work, and we’ll have it ready within two working days. If the content arrives late, it moves with it.”
Then update the promise as soon as the range moves, not at the deadline. A client told on day one that the work will run a day long is usually fine. A client told at the deadline usually isn’t.
Over time, your promises start landing where you said they would. That reliability is worth more to most clients than a shorter estimate that slips.
Where ActionOrder fits
On the Pro and Business plans, people log time on the card they’re working on. ActionOrder suggests an estimate from logged time on similar cards, and the person or their manager can change it. Cards running past their estimate show up on the team view, and logged time exports to CSV. See the use case for billing every hour to a task.
Questions people ask
Why are time estimates almost always too short?
Most estimates are built from the plan: list the steps and guess each one. That leaves out the delays and surprises that usually happen. In a classic 1994 study, even students’ worst-case estimates for finishing a thesis were shorter than the time it actually took them.
How do I estimate work my team has never done?
Set an appetite instead: decide how much time the work is worth and ask the person to stop and check in if it’s heading past that. Basecamp’s Shape Up method calls this fixed time, variable scope. Once the work has been done a few times, switch to estimates from logged time.
Should estimates be a single number or a range?
A range is more useful. Plan with the typical time, the middle of your history for similar work, and make promises with the time most similar tasks finish within. A wide gap between the two tells you the work isn’t well understood yet.
Won’t asking people to log time make them feel watched?
It can, if logs are used to rank people. Keep logged time self-reported and tied to tasks, let each person see their own numbers privately, and compare kinds of work rather than people. Used that way, logs make estimates better for everyone.
Sources
- Exploring the “planning fallacy”: Why people underestimate their task completion times (1994)Buehler, Griffin and Ross, Journal of Personality and Social Psychology
- From Nobel Prize to Project Management: Getting Risks Right (2006)Bent Flyvbjerg, Project Management Journal
- Shape Up, Chapter 3: Set BoundariesRyan Singer, Basecamp
