Use Case · Estimate Quality Drift
On fixed-price projects, the estimate determines the price, so every hour beyond the planned effort reduces the margin. Tolmete compares progress with approved time while delivery continues and identifies drift before the financial impact reaches next month’s P&L.
It is Wednesday, midway through the sprint, and Payments is the largest workstream on this fixed-price project. During the weekly delivery call, Olivia asks for a quick progress update.
Bob's update is accurate because the feature is about 50% complete, yet the picture changes when progress is compared with time spent. Payments was estimated at 120 hours, so the planned burn at this point was 60 hours. The team has already logged 84 hours, putting the feature at 1.4× its planned pace. If that pace continues, Payments will finish at roughly 168 hours.
No one is concealing the overrun. Estimates are recorded in tickets, while actual hours are tracked in time logs. Because the two numbers remain separate during delivery, the project board can stay green after the economics have moved off plan.
One inaccurate estimate may be an isolated error. Estimate drift appears when several features repeatedly consume effort faster than they progress, while status calls continue to sound normal.
This pattern affects development shops, agencies, studios, and consultancies because they often price work at times of highest uncertainty. Under fixed-price contracts, the company carries the additional cost as a loss of margin. On T&M, the client receives an invoice that no longer matches the forecast.
The commercial impact differs, although the reporting failure remains the same. Project boards, timesheets, and the monthly P&L reveal the damage after the useful decisions have already narrowed.
The difference between estimated and actual effort rarely manifests as a single obvious failure. It grows through several smaller patterns that seem reasonable when viewed separately.
Boards track whether tickets move; time logs record the hours. Neither shows whether the progress achieved matches the budget consumed. A feature can run at 1.4× its planned pace for weeks while every standup reports steady progress. When the numbers are compared only after delivery, they explain where the budget went, but they cannot recover it.
Re-estimating is reasonable when scope changes or an assumption fails. The problem begins when the original estimate is overwritten, and the change history is lost. The report returns to green because the budget has grown, while the initial variance disappears. After several revisions, the project can look close to estimate even as its actual cost continues to rise.
Meetings, rework, support requests, and "quick fixes" all consume real time. If the work was never estimated, there is no budget against which to measure those hours, so they remain outside variance reports even though they still increase project cost. Under a fixed-price contract, the company bears the cost; under T&M, the hours appear on an invoice the client never saw in the forecast.
The hidden cost of estimate drift
1.4×
Burn pace on the biggest features: half the work done, seventy percent of the budget spent
Example evaluation, drifting fixed-price project1 in 4
Estimated tickets revised upward mid-flight, hiding the overrun in plain sight
Same 14-day evaluation window29%
Of all logged hours, landing on work, nothing was ever estimated for
Same 14-day evaluation windowHow Tolmete Approaches This
Tolmete already holds the hours your team has approved and logged, one side of the calculation. It combines them with estimates, completion data, and ticket history from Jira or Asana.
Across every active project, Tolmete tracks three patterns over rolling windows: burn relative to completion, estimates revised after work begins, and approved time assigned to unestimated work. Following these patterns over time helps distinguish normal variation from declining accuracy in estimates, so a single difficult ticket does not define the entire project.
The signal relies on project metadata and does not use screenshots, keylogging, or activity monitoring. Its findings remain at feature and project level, because the person completing the work may not have written the estimate or approved the scope.
Note what the signal is not doing. It did not fire because of one bad ticket, since a single outlier is noise, not drift. It fired because the trend exceeded a sanity threshold and worsened relative to this project's recent baseline. The signal also arrived with a plan: something to do today, something to address this sprint, and something to change for the next one. A signal without a plan is just bad news.
Tolmete works without a new reporting layer, using the records already produced during delivery and turning them into a clear basis for action when work begins to move beyond the agreed scope.
Estimates come from Jira or Asana in the form of hours, story points, or planned dates. Tolmete matches them at the feature level with approved time logs. If the project estimates in points or dates, the PM confirms the conversion once, so the system does not have to infer it.
Hours spent mean little without knowing how much work is done. Tolmete compares the share of the estimate consumed with the share of the feature completed. Payments has used 70% of its estimate at 50% completion, which puts its burn pace at 1.4×, or 40% above plan for this stage.
When the threshold is reached, the signal shows the scope movement, confidence level, and estimated billing exposure based on the agency's rate card. The PM can see whether the issue needs a quick note, a change request, or a client conversation.
On fixed-price work, the priority is protecting margin by re-estimating the remaining effort and pausing new scope. For time-and-materials work, the priority is protecting the client relationship by sharing a revised forecast before the change is reflected on the invoice. Each plan covers three horizons: contain the exposure today, correct the current drift this sprint, and change the process next sprint.
Margin risk becomes visible during the sprint, weeks before it appears in the P&L.
A drifting feature can be re-estimated at 50% completion instead of being discovered at 100%.
The client receives a revised forecast while options remain, rather than an unexplained invoice later.
The estimator and the person delivering the work are often different people. The variance may come from incomplete discovery, a failed technical assumption, or a scope decision that changed the amount of work required.
In fixed-price projects, the scope conversation can happen while budget and delivery options are still available. On T&M, the account manager can explain the revised forecast before the client encounters an unexpected charge.
Each completed evaluation window also strengthens the project's baseline. Over time, Tolmete judges current drift against the project's history of estimates instead of applying a single generic benchmark to every team.
Tolmete works with the estimates your team already maintains in Jira or Asana, as well as the hours it already logs. It uses recent work to build an accuracy baseline for each project, then evaluates every rolling window across all active projects.
The signal surfaces only when the trend is real. When the data cannot support a verdict (thin logging, missing estimates, an unconfirmed points convention), it asks or remains silent instead of assuming.
Jira, GitHub, Slack · ~3 min per tool
The project baseline
Burn against completion across every active project
The project is the same, and Payments is still running above its original plan. This time, the drift surfaces during the sprint in the same conversation where the team already discusses delivery.
The signal cannot recover the hours already spent, but it changes when the team responds. At hour 84, the PM can still revise the remaining plan, pause new requests, and discuss scope with the client. By hour 168, most of those options have disappeared.
The inaccurate estimate also serves as evidence for future planning, not as a verdict on the engineer who inherited it. The team can correct the planning assumption without turning project variance into an individual performance judgment.
Your KPIs tell you what happened. Not what's about to.
The Old Way
The drift was present in the data, although progress and effort were never evaluated together.
The Automated Way
The same team continues working on the same feature, with the decision arriving early enough to change the outcome.
Every service company already produces the two figures needed to identify estimate drift: what the work was expected to cost and what it is currently costing. The financial risk increases during the interval between when those figures are recorded and when someone evaluates them together.
Tolmete reduces that interval to one evaluation window. It quantifies the drift, compares it with the project's history, assesses the quality of the evidence, and provides the team with a plan while the feature can still be changed.
During that interval, burn continues to rise, estimate revisions can obscure the original variance, and unestimated work continues to add cost. Once those effects appear in the monthly P&L or the client invoice, the project may clearly reflect the loss, leaving few options to reduce it.
See the burn.Understand the cause. Act before the sprint closes.
Self-Serve
Connect Jira and GitHub, tuned to your projects within days. No credit card, no demo call required.
Talk to Us
For teams 25+ or with enterprise needs: dedicated SLA, SSO, custom integrations, and onboarding support.
Tolmete helps development shops, agencies, and other service companies detect estimate drift while projects can still be corrected, before costs reach the margin, the invoice, or the client relationship.
