Who Estimates the Work Changes How the Work Goes

A few years into coaching, I worked with a team that had done everything right on paper and was still stuck.

Eight engineers. Hand-selected. All senior. They built entertainment features for large web portals in European markets, and they had been running Scrum by the book for seven months on one-month sprints. They’d seen real gains early on. Then delivery started slipping, and it kept slipping. Business unit owners needed to ship to stay competitive, and they needed to know what would actually be done at the end of each sprint. They weren’t getting either.

When I came in, the team was confident the problem would surface fast. Seven sprints of history, one obvious culprit, exercise over by lunch. That’s not how it went.

Ruling things out is most of the work

The first question wasn’t “what’s wrong,” it was “is the claim even true?” Teams that feel behind are not always behind. So we started with whether the team was actually failing to deliver what it committed to.

It was. Across all seven sprints, a meaningful chunk of committed work ended each sprint either still in progress or never started. Stakeholders were not getting what they asked for. That much was settled quickly.

Plan size told a second story. In sprints three and four, the plan grew 36% and 27% between start and finish — work being added mid-sprint, after the commitment was made. The other sprints were tamer, in the 1–8% range, but the pattern was clear enough: the plan was not holding still.

Then came the part that surprised everyone, including me. We plotted task variance three ways:

• By sprint. No trend. The team wasn’t getting steadily worse or steadily better.
• By owner. No trend. There was no one dragging the average down, no hero holding it up.
• By work type. No trend. Bugs, features, preconditions, spikes, tax work, testing — all roughly the same spread.

This mattered enormously, because every one of those was a hypothesis someone on the team held privately. It’s not the new guy. It’s not the testing. It’s not that we started strong and burned out. The data said no to all of it.

What the data did say: the average task finished 1.07 hours late, with a variance of 3.2 hours. In practice that means any given task was likely to run about an hour long and could easily run four. Stack that across a sprint’s worth of tasks and you get a team that cannot make a commitment it can keep — not because anyone is slow, but because nobody can see the edges of the work clearly enough to bound it.

Constants, noise, and things worth experimenting on

To find causes, we ran an Ishikawa exercise and sorted what came out into three buckets.

Noise was everything real but not actionable in this cycle: timesheet updates, turnover in roles, attitudes about Scrum, C# requirements, company political silos, market changes, new technology. Real friction, all of it. None of it was going to move the needle in the next eight weeks, and chasing it would have burned the team’s credibility. We crossed it out.

Constants were the structural things the team owned: no clear definition of “done,” too many open tasks per person, no standard demo meeting format, not enough test machines.

Experimentals were the things we could change and measure: subject matter experts estimating work they didn’t do, a small handful of SMEs doing all the estimation, and sprints that ran too long.

Then we scored each candidate against the three outcomes the business actually cared about — estimation accuracy, features completed, and customer demos. One item came out on top by a wide margin: a few SMEs do all the estimation.

That was the finding. The people producing the numbers were not the people doing the work.

The changes

Five, introduced together:

What happened

The team finished 96% of its work. Task lateness dropped from 1.07 hours to 0.13 — nine-tenths of an hour recovered per task. Variance dropped from 3.2 hours to 1.5, which is the number I care about most, because variance is what predictability is actually made of. A team that’s consistently a little late can be planned around. A team that might be four hours late on anything cannot.

And here’s the part that mattered to the business: the number of hours planned per sprint did not go down. The team didn’t buy predictability by sandbagging. They planned the same amount of work and simply started finishing it.

The softer results were harder to chart and just as real. Morale went up. Job satisfaction went up. Quality went up, carried by unit and acceptance tests that the done list now required. Customers were happier. Knowledge spread — the team started turning into specialized generalists rather than a set of silos with a person in each one. And there was more trust, in both directions.

Why estimating together works

None of this is mysterious, and it isn’t new. Planning poker is a descendant of Wideband Delphi, which RAND was working on in the late 1940s. The mechanics are simple: everyone gets a deck, the highest-priority story comes up, the team discusses it, everyone picks a number privately, and everyone reveals at once. Close numbers — a spread of 2s and 3s — need no further rounds. A spread of 2s and 8s absolutely does, because that gap is a disagreement about the work, not about arithmetic. You repeat until you converge, then move to the next story.

What makes it work:

• The people who will do the work are the ones estimating it (Jørgensen, 2004).
• Estimators have to justify their numbers out loud, which changes the quality of the reasoning behind them (Hagafors & Brehmer (paywall), 1983; Brenner et al., 1996).
• Combining individual estimates through group discussion beats individual estimates alone (Höst & Wohlin (paywall), 1998; Jørgensen & Moløkken, 2002).
• Relative sizing beats absolute sizing, and a constrained set of card values keeps arguments from becoming meaningless.
• Everyone’s opinion gets heard.

But the effect I didn’t fully anticipate was on ownership. Before, the sentiment was “I own my task.” After, it was “I own the delivery of the system.” Estimating together means the team estimates the work rather than signing up for it, and the discussion that produces the estimate is where people learn the system — and learn each other’s strengths and weaknesses.

What you can take from this

Build a Definition of Done, and build it at every level. What does done mean for a task? A story? A sprint? A release to integration? A release to production? Write it down, make it concrete — installation package updated, 70% code coverage, architecture diagrams updated, stress testing complete, disaster recovery plan tested — and share it with your customers. It builds a bond inside the team, it tells stakeholders exactly what they’re getting, it keeps technical debt from being quietly deferred to the end, and it keeps everyone pointed the same direction.

Estimate effort, derive duration, and use ranges. Use planning poker at the product backlog level. Use it at the task level too, if the team is ready for it.

Clear blocking issues promptly. Blockers change estimates. The number of blockers a person is carrying maps almost directly to how little value is flowing through them, because every blocker is another context switch — and people forget. If someone has ten open blocking issues, something has gone badly wrong before you ever get to estimation.

Keep work in progress small. Three open tasks at a time. No more.

The lesson I keep coming back to from this engagement isn’t about a technique. It’s that a team of excellent, senior, well-intentioned engineers was stuck for seven months on something that turned out to be a question of who was in the room. The estimates weren’t bad because the estimators were bad. They were bad because the estimators weren’t the ones who’d have to live with them.