How Tracking Working Time Fixed Our Broken Estimates

In this example, a delivery team had a familiar disease: every estimate was wrong, and they kept making the same wrong estimates anyway. The cure turned out to be unglamorous—tracking working time on actual work and letting the data correct their instincts. Here’s how one composite team turned guesswork into grounded planning without turning timekeeping into a surveillance nightmare.

The estimates that were always wrong in the same direction

The team estimated in story points and gut feel. Sprint after sprint, the same pattern repeated: QA and review work consistently took longer than anyone planned, and the team consistently over-committed.

The root cause wasn’t laziness—it was a missing feedback loop. They had:

• No record of how long anything actually took. Estimates were never checked against reality, so they never improved.
• A blind spot around testing. Everyone “knew” QA took a while, but nobody could say how long, on which repos, or for which kinds of work.
• Recency bias. The last painful PR dominated the next estimate, regardless of whether it was typical.

They were forecasting with no historical data. Predictably, the forecasts were fiction.

The fix: track time on the work itself

The change was small in effort and large in effect. Testers started a timer when they began working a piece of work—a testing session tied to a specific pull request—and stopped it when they finished.

start session  →  PR #482, repo: billing-service
...work...
stop session   →  elapsed time recorded against that PR, repo, and label

No timesheets, no manual logging at day’s end, no estimating-after-the-fact. The timer attached effort directly to the work, so the data was a byproduct of doing the job rather than a separate chore.

Reports that turned hours into decisions

Raw hours don’t fix estimates—structured hours do. The workspace let the team slice their tracked time five ways:

• By tester — to balance load and spot who was quietly overloaded.
• By day — to see where time actually went across a sprint.
• By repository — to find which codebases ate disproportionate effort.
• By pull request — to compare estimated vs. actual at the unit of work.
• By label — to compare effort across workflow states like passed and failed.

Each cut answered a question they’d previously argued about with no evidence.

What the data told them

A few findings, in this example, reshaped their planning:

1. One repository was a time sink. Reports by repository showed a single service consistently consumed far more QA time per PR than the others. That justified investing in better test scaffolding there instead of just absorbing the cost every sprint.
2. Failed PRs were expensive—more than they felt. Reporting by label revealed that failed work, with its re-tests, cost dramatically more total time than passed work. That nudged the team to tighten their “definition of ready” upstream.
3. Load was lopsided. Reports by tester showed effort wasn’t evenly distributed. They rebalanced based on hours, not vibes.

Better estimates, almost as a side effect

Once they had a few sprints of tracked time, estimating stopped being a guessing game. Instead of “this feels like a 3,” they could say “PRs touching the billing service have historically taken roughly this long, and this one’s bigger.”

The improvements compounded:

• Estimates calibrated to reality. Comparing estimated vs. actual per PR gave them a correction factor they actually applied.
• Commitments got honest. Knowing QA’s real throughput, they stopped over-committing each sprint.
• Upstream investment got justified. “This repo costs us X hours of QA every sprint” is a far stronger argument for tech-debt work than “it feels slow.”

Keeping it humane

The team was careful about one thing: time tracking can curdle into surveillance, and surveilled teams game the numbers. They set ground rules that kept it useful:

• Track work, not people. The goal was estimating better, not policing individuals. Reports informed planning, not performance reviews.
• Make it frictionless. A start/stop timer on a PR is low-effort; manual timesheets are not. Low friction kept the data honest.
• Share the insights openly. When the whole team saw the repository and label reports, the data became a shared tool rather than a manager’s secret.

A starter playbook for fixing your estimates

If your estimates are reliably wrong, try this:

1. Track time on the actual work, tied to the specific PR, via a simple start/stop timer.
2. Don’t estimate after the fact—capture effort as it happens so the data stays trustworthy.
3. Read the reports by repository and label first. These usually surface the biggest, most fixable cost drivers.
4. Compare estimated vs. actual per PR and apply the correction to future estimates.
5. Keep it about the work, not the worker, so nobody games the timer.

Key takeaways

• Broken estimates usually come from a missing feedback loop: no record of how long work actually took.
• Tracking working time on real PRs—via a low-friction start/stop timer—creates that loop as a byproduct of doing the job.
• Reports by tester, day, repository, PR, and label turn raw hours into specific, defensible planning decisions.
• Keep time tracking humane: measure the work, not the worker, or the data stops being trustworthy.

If your estimates keep missing in the same direction, KazTrack’s testing-session tracking and per-PR, per-repo, per-label reports give you the history to fix them—a grounded place to start.