How Teams Actually Finish What They Start, Part IV: Point After the Fact

Mon, 04 May 2026 00:00:00 +0000

TL;DR

Forward estimation breaks for any team whose week is shaped by work that arrives. The discipline that scales is to point after the fact: when the ticket closes, the person who did the work writes down what it took. Over a quarter the team has real data about where time actually goes.

Standup Monday. A 5-point ticket lands in the engineer’s column. Wednesday the engineer is still on it, two production fires deep, the original scope half-discovered. By Friday it ships. The retro looks at velocity. The 5 stays a 5, the team’s data says the engineer did 5 points of work, and the next sprint’s planning uses that data to size the next ticket of the same shape. The bug compounds.

Better estimates don’t fix it

The obvious move is to estimate better: planning poker, three-point estimates, finer story points, more grooming up front. None of it works on a team whose week is shaped by inbound work. The variance is not in how the engineer reads the ticket. It is in what arrives between Monday and Friday. A ticket scoped honestly Monday gets eaten by an unrelated incident Wednesday. A 5-point ticket stays 5 points until the dependency the engineer didn’t know about turns it into 13. Forward estimation is trying to predict the team’s week, and the team’s week is not predictable.

Point what you did

The fix is mechanical. When the ticket closes, the person who did the work writes down what it took. Over a quarter the team has real data: which categories of work consume the most time, which engineers carry which kinds of load, where the same shape of problem keeps eating a day each time. The cost is near zero (the ticket is closed; the person who did the work is sitting there). Bottlenecks surface fast: a category that always takes three times what its siblings take is a place to invest, and the data makes it visible without anyone having to argue for it.

The rule has to be load-bearing in the workflow, not aspirational. A ticket cannot move to Done without a points value. Without that constraint, the data has gaps, and the gaps are not the random kind.

Half-pointed data is worse than no data

Without a load-bearing constraint, easy tickets get pointed and hard tickets get closed in a rush. The long-tail work the team most needs to see disappears from the record. The team trusts the partial data anyway and reaches the wrong conclusions about its own capacity.

What the data enables

Operation-heavy teams can drop forward sprint commitments entirely. The manager sets priorities through labels on tickets and epics. The team pulls from the top of the labeled backlog as engineers free up. After-the-fact points accumulate over the quarter and give the team a real baseline: capacity, distribution, ticket-shape patterns. Forecasting becomes a quarter-long view rather than a sprint-long commitment.

The same data benchmarks people. Recurring work converges in shape over a quarter. Responder rotations cluster around the same handful of incident types. Refactors pattern-match to a few common shapes. When ten engineers have closed the same kind of ticket, the spread of points across people becomes visible. Reviews stop being a debate about effort and become a comparison against work everyone has done. The conversation shifts from “I think Alice ships fast” to “Alice closes the same shape of ticket in 6 points where the team median is 8.”

Compare same shapes, not raw velocity

The benchmark only works for like-for-like work. A frontend ticket and a database investigation are not on the same scale. Group tickets by shape (incident type, refactor pattern, investigation category) before comparing engineers, and ignore raw point totals across the team.

When forward estimation works

Forward estimation works when the team’s work is genuinely stable: same shape every week, predictable interruptions, no unscoped depth. Some maintenance teams have this. Most product teams and most operational teams do not. The point of measuring after the fact is to find out which side your team is actually on, and to design the cadence around the answer.

What changes over a quarter

A team that points after the fact has a quarter’s worth of evidence about itself: which work consumes time, who is faster on what, where the bottlenecks live. A team that points before the fact has a quarter’s worth of guesses, refined and re-litigated each sprint. Retros become data-driven instead of opinion-driven. Reviews compare engineers against the same shapes of work. And when the team asks for headcount, the ask is grounded in a category that has been swallowing unbudgeted time, not a hunch.