The last estimating session I sat in on lasted eleven minutes. Somebody pasted the scope into an assistant, it came back with "14–18 weeks, moderate confidence," and the room spent the remaining time deciding whether sixteen or seventeen sounded right. It was efficient. Everyone left on time. Three weeks later the integration lead quietly mentioned that nobody had talked to the team that owns the upstream feed, which is where the schedule actually went to die.
That's the part I want to pull on. The number wasn't obviously wrong. It was plausible, which is worse. A plausible number that nobody built is a very hard thing to push back on, because the person pushing back has to produce a competing number from nothing, in real time, against something that arrived looking finished.
The argument was the estimate
Anyone who has run planning poker well knows the value was never the median. It was the moment two people turned over a 3 and a 13 and had to explain themselves. The person who said 13 knew about the data migration nobody else had remembered. The person who said 3 had done this exact integration before and knew the vendor's sandbox was fine. The number that came out the other end was almost incidental. What the team actually produced was a shared list of risks and assumptions, and a shared sense of what they had just committed to.
Estimation is a discovery process wearing a numeric costume. You surface the unknowns by being forced to put a figure on them. Remove the forcing function and you keep the figure and lose the discovery. The assistant's list of assumptions looks like the same artifact, but it is a generic list about work in general. Yours would have been specific, uncomfortable, and named after real people on your program.
What breaks when the number comes first
1. The anchor sets before anyone thinks
Anchoring is among the best-documented effects in behavioral research: the first figure in the room pulls every later estimate toward itself, even when people know it's arbitrary. A human who throws out a number first is at least known to be guessing. A machine's number arrives with a range, a confidence label, and the full authority of fluent prose. Nobody in the meeting says "that feels light" when the system has already said "moderate confidence." So the team adjusts the number by a week in either direction and calls that estimating.
2. Ownership never forms
People defend estimates they made and resent ones they were handed. When a developer says "three weeks" out loud to their peers, they've made a small public promise, and they will work to keep it. When an assistant says three weeks, the developer has been informed of a fact about their own future. This is the same gap I wrote about in the plan nobody agreed to, one level down: the commitment hasn't been made by anyone, so when it slips, nobody feels they broke it.
3. The confidence label is decoration
"Moderate confidence" sounds like a calibrated statement. It isn't one. The model has no view of your upstream team, your procurement cycle, or the sponsor who changes their mind every quarter, and it sounds identical whether the scope was thoroughly described or loosely guessed at. It's the confidence problem applied to the one number a program will be measured against for the next year.
An estimate is only worth something if somebody can be asked why they believe it. A number nobody built has nobody to ask — and that is exactly when a program discovers it has been steering by a guess with good manners.
Put the humans back before the number
I'm not arguing against using the tool. A model is a good second opinion on scope you've already thought about, and it's quick at spotting the dependency you forgot to list. The mistake is the sequencing. Reverse it: the team estimates first, privately and independently, then the machine's figure goes on the table as one more voice. When the human numbers and the machine's number disagree, that gap is the most useful thing in the session. Chase it.
Then make the owner explicit. Every estimate that goes into a baseline carries the name of the person who will be held to it, and that person has to be able to say, in their own words, what would make it wrong. If they can't, you don't have an estimate yet. You have a draft. The rubber-stamp problem applies here too: a lead who signs off on a figure they didn't build is not reviewing it, they're relaying it.
Finally, keep the track record. Log each estimate, its owner, and what actually happened, and review it at the quarter. Over a few cycles you learn whose numbers hold, which kinds of work run long, and whether the machine's ranges mean anything on your program. That calibration is the only thing that turns a confidence label from decoration into information, and no vendor can ship it to you.
- Have the team estimate independently before anyone sees the machine's number. The first figure in the room becomes the anchor, so make sure it's a human one.
- Treat disagreement between human and AI estimates as the finding. The gap points at an assumption somebody hasn't said out loud.
- Attach a named owner to every baselined estimate, and require them to state in their own words what would make it wrong.
- Ask for the assumptions to be specific to your program: named teams, named dependencies, named decisions. A generic list is a sign nobody did the thinking.
- Log estimates against actuals and review them quarterly. Calibration is earned from your own history, not from a confidence label.
The bottom line
Cheap estimates feel like progress, and for a few weeks they are. The meetings shrink, the plan appears faster, and the sponsor gets a date. Then the first dependency nobody discussed turns up, and the team realises the shared understanding the old process produced as a byproduct was the thing they were quietly relying on. A number is easy to generate. What a program needs is people who know why they believe it. If the tool gave you the number, make sure your people still have to earn the belief.