Time tracking in projects: why your estimates are always off
Ask a team how long a task will take. Write the answer down. Then measure how long it actually took.
The ratio is almost always between 1.5 and 3. Not on individual outliers — on average, across all tasks, in nearly every team.
That is not incompetence. It is a well-studied cognitive error, and you can calculate around it instead of fighting it.
Why estimates are systematically too low
We estimate the path, not the detours. When estimating you picture the straight line: sit down, do it, done. What you leave out is the question that stays unanswered for two days, the bug in the library, the meeting that lands in the middle.
We estimate pure working time. You mean four focused hours. What gets measured is a working day with a standup, emails and three interruptions.
We remember charitably. The last similar task felt like "two days". Measured, it was four. Without a record, the feeling wins.
Optimism is socially rewarded. Saying "three days" in planning makes you look capable. Saying "eight" means defending yourself.
The only number you need
Instead of guessing better, measure your own factor:
Factor = sum of actuals / sum of estimates
Four weeks is enough. After that you have a number — say 1.8. From then on you multiply every estimate by it.
It feels like cheating. It is not. The factor is the measured gap between your imagination and your reality. It shrinks over time, precisely because you know it.
Important: one factor per team, not per person. Otherwise a metric becomes a performance comparison — and then the times get massaged, and the number is worthless.
What to measure, and what not to
Time tracking has a bad reputation because it is often used for surveillance. For better estimates you need surprisingly little:
Needed:
- Time per task (not per person)
- The original estimate, kept unchanged
- Whether the task was blocked, and for how long
Not needed:
- Who started when
- Breaks
- Activities below task level
The third item in the first list is the underrated one. If a task runs from eight planned to twenty hours, but twelve of those were waiting on a delivery, the estimate was right — the problem was elsewhere. Without that separation you correct the wrong thing.
Which is why it pays to record dependencies on the ticket: blocked time becomes visible instead of disappearing into working time.
Tracking that actually happens
Any time tracking that costs extra steps will, after two weeks, be filled in retroactively from memory — and then it measures nothing.
Two rules:
- No more than one click. Zero is better: in ORBYLOX the timer runs by itself as soon as someone works in the project.
- Visible to everyone, evaluated for no individual. The moment times appear in performance reviews, the data is ruined.
A worked example
A team estimates a sprint at 120 hours. Measured: 210. Factor 1.75.
Next sprint they estimate 120 again and plan with 120 × 1.75 = 210. They come in at 205.
Not because they got faster. Because the plan finally matches reality — and because nobody has to finish a task on Friday evening that was never doable in two days.
Four steps to start
- Record the estimate when creating the task, and never change it
- Capture actual time — automatically, not through a form
- Keep blocked time separate
- After four weeks, compute the factor and apply it from then on
How to cut tasks so that estimating makes sense at all is covered in How to create a project plan.
In ORBYLOX time tracking runs automatically per project — free, no extra tool.
