The planning poker session has entered its second hour.
The story is not especially large. It is a reporting change, a new filter, a small export path, something that sounds simple until the team starts naming the dependencies. The designer is not sure whether empty states are final. The backend engineer thinks the query can reuse an existing index, but only if the permissions layer behaves the way everyone hopes it behaves. The product manager wants a number before the roadmap review. The senior engineer says five. Someone else says eight. A third person says thirteen because they remember the last time a report seemed harmless.
The team does what the ritual requires. It explains. It votes again. It narrows. It debates whether risk belongs in the point value or in a separate note nobody will read. Eventually a number appears in the tool. The meeting moves on. The number looks clean because numbers always look cleaner than the conversation that produced them.
Nothing important has become certain.
This is estimation theatre: the organisational performance in which uncertainty is converted into a number, the number is converted into a plan, and the plan is converted into moral pressure. Everyone involved knows the number is provisional. Everyone also knows it will be screenshotted, rolled into capacity, turned into a date, compared against velocity, and remembered when the work slips.
The theatre persists because it solves social problems even when it fails at forecasting. Managers get a sense of control. Product teams get a planning object. Finance gets something that resembles a cost. Executives get a roadmap. Developers get a shield: the team estimated the work, the uncertainty was discussed, the number was not invented by one unlucky person in a hallway.
That shield matters. Estimation is not only a prediction mechanism. In many organisations, it is also a blame allocation mechanism. A missed commitment is easier to discuss when it has a ritual origin. The team did the process. The cards were shown. The sprint was planned. If the date moved, the failure can be framed as execution, scope change, dependency delay, or optimism bias rather than an admission that the organisation demanded certainty from a system that could not provide it.
That is the collective delusion. Not that estimates are always worthless. They are not. The delusion is that repeating the ritual can make uncertain work behave like known work.
The ritual is bigger than the estimate
Scrum's own guide is more modest than many Scrum-like organisations. The 2020 Scrum Guide describes Scrum as empirical and lean, says that in complex environments only what has already happened can be used for forward-looking decisions, and warns that forecasts such as burn-downs and cumulative flows do not replace empiricism.1 It also defines the formal events: Sprint Planning, the Daily Scrum, Sprint Review, and Sprint Retrospective. For a one-month sprint, planning is capped at eight hours, review at four, retrospective at three, and the Daily Scrum at fifteen minutes each working day.1
Those events are not bad. Done well, they create shared understanding, inspect real progress, and adapt the plan. The problem begins when the ritual stops being inspection and starts being proof. A planning meeting is supposed to expose uncertainty. In many organisations it is used to erase uncertainty.
The difference is visible in what happens to the estimate after the meeting. A healthy estimate carries its assumptions with it. It says this work is small if the permissions layer behaves, medium if the export path needs a new queue, and large if the customer data model is wrong. It says the team has seen similar work before or has not. It says the plan depends on one person being available. It says the range is wide because the discovery is unfinished.
The theatrical estimate sheds all of that and survives only as a point value.
Steve McConnell's 2006 chapter from Software Estimation makes the distinction plainly. Software estimates are routinely presented as single-point numbers, but a single point without probability information is not meaningful. McConnell argues that a single-point estimate is often a target disguised as an estimate, and that useful estimates need ranges or explicit probabilities.2 The idea is simple enough that every experienced engineer recognises it. The outcome is rarely the exact middle of the guess. A schedule has a distribution.
Organisations dislike distributions. A distribution is awkward to put on a quarterly roadmap. A range makes budget conversations harder. A probability forces leadership to admit that a date might be a bet, not a promise. So the probability disappears. The estimate becomes a number. The number becomes a commitment. The commitment becomes a test of professionalism.
That conversion is the theatre.
The team did not necessarily estimate badly. It may have estimated honestly, given the information it had. The organisation then laundered the estimate into a different kind of artefact, and by the time the work starts, nobody can quite remember where the uncertainty went.
This explains why teams can spend years improving the ceremony while leaving the failure mode intact. They switch from hours to story points, then from story points to T-shirt sizes. They use Fibonacci numbers and silent voting. They require acceptance criteria. They split stories smaller. They add capacity spreadsheets, then a second refinement meeting so the planning meeting can be shorter. All of that can help, but none of it fixes the central mistake if the final artefact is still treated as certainty.
The question is not whether estimation should exist. The question is what job the estimate is being asked to do. If it is used to decide whether a feature is worth exploring, compare options, expose missing information, or decide which risk to reduce first, estimation can be useful. If it is used to turn unknown work into a promise the organisation was already hoping to make, it is theatre with arithmetic.
The numbers keep losing to reality
Software estimation is not weak because engineers are uniquely incompetent at guessing. It is weak because software work often contains discovery. A team is not merely assembling known parts at known rates. It is learning what the product actually needs, what the legacy system actually does, what the dependency actually permits, what the customer actually meant, and what the code actually makes expensive.
The research record reflects that mess. Kjetil Molokken and Magne Jorgensen reviewed surveys on software effort estimation and reported that most projects, roughly 60-80%, encountered effort or schedule overruns. They also cautioned that the overruns appeared lower than some consultancy reports claimed, with many surveys suggesting average effort or cost overruns nearer 30-40%.3 That caution is important. The point is not to repeat the largest scary number. The point is that overruns are common enough that pretending point estimates are stable is not a serious planning posture.
Jorgensen's later review of expert estimation found that expert judgement was the dominant strategy in software effort estimation, and that there was no substantial evidence favouring formal estimation models over it. Good estimation practice, the review suggested, depends on unglamorous things: historical data, independent top-down and bottom-up estimates, uncertainty assessment, feedback, and training.4 In other words, the literature does not say humans should never estimate. It says estimation is a skill, a process, and a feedback system. Most organisational rituals keep the meeting and omit the feedback system.
That omission matters because people are systematically vulnerable to optimistic planning. Roger Buehler, Dale Griffin, and Michael Ross documented the planning fallacy in 1994: people reliably underestimate how long their own tasks will take, even with their own history of late tasks available to them.5 Daniel Kahneman and Dan Lovallo had described the mechanism a year earlier as the inside view: decision makers treat the current problem as unique, build forecasts around plans and scenarios, and neglect the statistics of past cases.6
Software teams do this constantly. They do not ask how long similar migrations took across the last ten projects. They ask whether this migration seems hard. They do not ask how often the team completed report changes of this size within a sprint. They ask whether this report feels like a five. They do not ask how many times auth changes have surprised them. They ask whether this auth change has any obvious surprises.
The inside view feels responsible because it is detailed. The team discusses the actual feature, the actual data model, the actual dependencies, the actual engineer who will probably do the work. That detail creates confidence. It also creates blindness. The team can talk for an hour about a story and still underweight the boring base rate: work like this usually takes longer than the room wants it to take.
Estimation theatre amplifies the inside view because the ritual rewards story-specific persuasion. A confident engineer who can explain a path through the work can pull a number down. A cautious engineer who remembers three similar disasters can be framed as pessimistic unless they can prove the disaster will recur. But the whole problem with uncertainty is that nobody can prove which hidden condition will matter.
The result is a familiar pattern. The early estimate is too small. The work starts. The permissions layer does not behave the way everyone hoped. The team revises the plan. The organisation treats the revision as slippage rather than learning. The next planning session starts, and the same organisation asks for another clean number.
That is not planning. It is amnesia on cadence.
Story points became a shield
Story points were meant to avoid some of this damage. They moved teams away from pretending a story could be precisely converted into hours. They encouraged relative sizing. They made discussion visible. They gave teams a way to forecast based on throughput instead of individual developer promises.
Then the points were captured.
Story points can become hours with a costume. A point acquires a private exchange rate. Velocity becomes capacity. Capacity becomes a target. The team is told not to compare velocities across teams, then the comparison appears anyway. Developers are told points are not commitments, then sprint failure is discussed in exactly those terms.
The method is not the whole problem. The surrounding incentives are.
Planning poker, for example, has a defensible aim. It tries to make estimation collaborative, reduce anchoring by revealing estimates at the same time, and force discussion when estimates differ. Viljan Mahnic and Tomaz Hovelja's 2012 study is useful because it does not reduce the method to either magic or nonsense. It found that planning poker increased over-optimism among inexperienced student teams, while estimates from experienced professionals using planning poker were closer to actual effort and tended to be more accurate than a statistical combination of their individual estimates.7
That is exactly the kind of nuance theatre hates. The study does not say planning poker works. It does not say planning poker fails. It says context matters: experience, feedback, group dynamics, and the nature of the work all matter.
In the meeting room, that nuance disappears. Planning poker becomes a legitimacy ritual. The team used the accepted technique, therefore the estimate looks fair. The fact that the technique can produce over-optimism in some settings is not remembered when the sprint board is full. The fact that expertise matters is not remembered when the newest team in the company is expected to forecast a domain it barely understands.
This is where estimates become a shield for both sides of the organisation.
For management, the estimate shields desire. A roadmap can include a date because the team provided numbers. The date no longer looks like managerial pressure; it looks like a bottom-up forecast. For developers, the estimate shields refusal. The team can say the work does not fit because the points exceed capacity. The discussion moves from explicit engineering judgement to spreadsheet refusal.
Both shields are understandable. Neither is free.
The managerial shield can turn team participation into false consent. A team that estimates under pressure may appear to have agreed to a plan it never truly believed. The developer shield can turn engineering judgement into ceremony. Instead of explaining risk, tradeoff, value, and uncertainty, the team argues about whether a story is too large for the sprint arithmetic.
The deeper loss is that estimation starts replacing prioritisation. If a team says a feature is thirteen points, the organisation asks how to fit thirteen points. It may not ask whether the feature is worth thirteen points. It may not ask whether a smaller version would produce the same learning. It may not ask whether the deadline is real or inherited. It may not ask what decision the estimate is supposed to support.
An estimate can answer how big a piece of work might be. It cannot answer whether the work matters.
When estimation becomes the centre of planning, the organisation quietly avoids the more important conversations. What should be cut? What should be delayed? What is the riskiest assumption? What could be delivered in two days to test whether the rest is worth doing? Which stakeholder is asking for certainty because they need it, and which is asking because certainty is comforting?
Story points cannot rescue an organisation from weak product judgement. They can only make weak judgement easier to schedule.
The Standish temptation
Every argument about estimation is tempted by dramatic project failure statistics.
The Standish Group's CHAOS reports are the obvious source. They have been published since 1994, and InfoQ's coverage of the 2015 report said that edition studied 50,000 projects and changed the definition of success to include on-time, on-budget, and satisfactory result.8 The reports are useful as industry artefacts because they show how strongly software organisations have wanted a scoreboard for project success and failure.
They are less useful as a clean backbone for an argument about estimation accuracy.
There are at least two reasons to be careful. First, project success is not the same thing as estimate accuracy. A project can miss its original date and still create enormous value. A project can hit its date and budget and produce something nobody needs. InfoQ's 2015 interview makes this definitional problem explicit: the report had changed success criteria, and Standish's own representative said success was hard to define.8
Second, Molokken and Jorgensen's review explicitly cautions against the most dramatic consultancy numbers. Their survey review still found overruns common, but it also suggested the average magnitude was lower than some popular reports claimed.3 That should change how the evidence is used. The honest conclusion is not that one famous percentage proves estimation is fake. The honest conclusion is that software estimation has a persistent overrun problem, measurement is messy, and organisations should be suspicious of any ritual that makes uncertainty look tidier than it is.
The cone of uncertainty has a similar misuse pattern. It is often invoked to reassure teams that estimates naturally become more accurate as a project progresses. That can be true when learning is real and the work is being controlled. But Todd Little's 2006 IEEE Software paper challenged the simplistic version using project data from Landmark Graphics. He found that project-duration accuracy followed a lognormal distribution and that the uncertainty range was nearly identical throughout the project, conflicting with a popular interpretation of the cone.9
The lesson is not that uncertainty never narrows. The lesson is that it does not narrow by ceremony. It narrows when real information changes: working software exists, integration risk is retired, dependency behaviour is observed, scope is cut, product assumptions are tested, or historical throughput becomes relevant.
Teams often act as if talking about the work reduces uncertainty the way doing part of the work does. Sometimes it does. A good planning conversation can expose a missing requirement before it becomes a defect. But there is a limit to what discussion can reveal. The database either has the needed index or it does not. The old API either behaves as the documentation says or it does not. The customer either accepts the reduced workflow or they do not. The proof is frequently in contact with reality, not in more refined speculation.
This is why estimation theatre is so wasteful. It spends high-quality engineering attention trying to create confidence in conditions where the better move is to create evidence.
Instead of debating whether the export feature is five or eight, a team might spend an afternoon proving whether the data can be queried safely. Instead of refining a large epic for three weeks, it might ship a narrow path to learn whether the workflow matters. Instead of demanding quarterly precision, leadership might ask what decisions genuinely require a forecast and what decisions can be made incrementally.
The mature response to messy estimation evidence is not nihilism. It is better epistemology. Know what kind of claim is being made. Know how much evidence supports it. Know when the number is a forecast, when it is a target, when it is a budget, and when it is a wish.
Most estimation theatre begins by confusing those four things.
The theatre is organisational
The theatre survives because it is useful to the organisation even when it is not useful to the work.
Planning rituals create a sense of order. They make backlogs look governable. They give managers a meeting where anxiety can be converted into action items. They give executives a roadmap that appears to be connected to team-level reality. They give product managers a way to negotiate scope without admitting that prioritisation is political.
They also move emotional pressure downhill.
If leadership wants a date, product asks for estimates. If product wants confidence, engineering estimates smaller work. If engineering expresses uncertainty, the process asks for refinement. If refinement does not create confidence, the organisation asks for more detail. Eventually the team has spent hours proving that a number is uncertain, and the organisation writes down the number anyway.
That is why estimation arguments so often become moral arguments. The team that resists estimates is accused of avoiding accountability. The manager who asks for estimates is accused of not trusting engineers. The product owner who presses for dates is accused of caring more about roadmap optics than reality. Sometimes those accusations are true. More often, everyone is responding to a system that has confused commitment with certainty.
Accountability is not the same as prediction. A team can be accountable for working visibly, surfacing risk early, measuring flow, managing scope, making tradeoffs explicit, and delivering the most valuable next thing. That does not mean the team can know the future on demand. A manager can be accountable for allocating budget, sequencing work, and communicating risk upward. That does not mean forcing every uncertainty into a date improves the plan.
The theatre is strongest where estimates are used to avoid executive tradeoffs. If the whole roadmap is important, estimation becomes the device for pretending everything can still fit. The team is not asked what should be cut. It is asked how long everything will take. When the answer is too long, the estimates are challenged, sliced, revisited, or compared against another team's velocity until a tolerable version of the plan appears.
That version of the plan is not more true. It is more acceptable.
The developer shield has its own dysfunction. Teams learn to pad. They estimate defensively because every point can become a promise. They protect themselves with bigger numbers, then get criticised for lacking urgency. They learn that transparent risk becomes negotiation material, so they hide uncertainty inside story points and present risk as arithmetic.
The organisation then complains that estimates are inflated.
This loop is destructive because it teaches both sides to distrust the artefact they keep demanding. Management thinks engineers are sandbagging. Engineers think management will weaponise the number. Product thinks both sides are making the roadmap impossible. Finance thinks delivery is undisciplined. Everyone returns to the ceremony because removing it would expose the absence of a better governance model.
That is the real reason estimation theatre is hard to abandon. The estimate is not only a planning tool. It is a substitute for trust, prioritisation, measurement, and appetite.
Trust would let teams state uncertainty without being accused of evasion. Prioritisation would force leadership to choose what matters most. Measurement would replace some guessing with throughput, cycle time, and historical delivery data. Appetite would cap investment before scope expands to fill the available optimism.
Without those things, the estimate becomes overloaded. It must predict, justify, negotiate, defend, prioritise, and reassure. No number can survive that much organisational need.
Better planning has less drama
The alternative is not to stop planning. That is the lazy version of the anti-estimation argument, and it is wrong.
Businesses need forecasts. Teams need to compare options. Customers need some expectation of timing. Finance needs to know whether a body of work is a small bet or a major investment. Product leaders need to sequence dependencies. Engineers need to decide whether a design is worth its implementation cost.
The alternative is to stop pretending that all planning questions require the same artefact.
Some questions need estimates. How much effort might this migration require? What is the range? What assumptions dominate the range? What could make it smaller? What could make it explode? Where is the confidence weakest?
Some questions need experiments. Can the old payment provider support the new reconciliation flow? Does the export endpoint time out at real customer data sizes? Will users accept a manual approval step? Can the permissions model represent this case without a redesign?
Some questions need throughput. How many similarly sized changes does this team normally complete in a month? What is the cycle-time distribution? How often does work wait for review, design, legal, data, or another team? How much work is already in progress?
Some questions need appetite. How much is the organisation willing to spend learning whether this feature matters? What is the maximum time worth investing before the team must show evidence? What is the smallest version that would create a useful signal?
The name NoEstimates sounds more absolute than many of its practical ideas. Vasco Duarte's 2015 book is explicitly about measuring project progress without estimating, and InfoQ's 2015 interview frames the approach around value, predictability, frequent progress reporting, and adapting plans based on existing data.1011 Whether or not a team adopts that banner, the useful challenge remains: if the organisation already has flow data, why is it still treating each forecast as a fresh act of imagination?
The Scrum Guide makes a compatible point without the branding. In complex environments, it says, what will happen is unknown; only what has already happened can be used for forward-looking decision making.1 That is not a rejection of planning. It is a warning against ungrounded prediction.
Better planning is usually less dramatic than estimation theatre. It looks like maintaining historical data. It looks like splitting work until uncertainty is bounded. It looks like writing assumptions next to ranges. It looks like saying that a date has 50% confidence or 90% confidence, and meaning different things by those numbers. It looks like making product choices when the forecast is uncomfortable instead of asking engineers to make the forecast nicer.
It also looks like separating the estimate from the commitment.
An estimate says what might happen. A commitment says what the organisation will do. They are related, but they are not the same. A team may estimate that a feature will take four to six weeks and commit to a customer event in five weeks only if scope is negotiable. It may estimate that a migration is three months of work and commit to a six-week discovery phase. It may estimate that a roadmap item is too uncertain to schedule and commit to reducing uncertainty before the next planning cycle.
That distinction gives everyone more room to be honest. Engineers can expose uncertainty without sounding evasive. Product can make tradeoffs without pretending the team knows more than it does. Leadership can communicate risk without turning forecasts into guarantees. The organisation can still make promises, but the promises are made consciously, with the uncertainty visible.
The next planning poker session does not need to be abolished. It needs to be put back in its place.
If the conversation reveals disagreement, capture the disagreement. If the range is wide, preserve the range. If the estimate depends on an assumption, test the assumption. If the work is too large, slice it. If the deadline is fixed, negotiate scope. If the value is unclear, stop estimating and decide whether the work should exist.
The point of planning is not to produce a number. The point is to improve the next decision.
Estimation theatre begins when the organisation forgets that. It treats the number as the deliverable of planning. It rewards clean answers over honest ones. It converts forecasts into promises and then acts surprised when reality refuses to honour the spreadsheet.
Nobody needs another ritual to fix that. They need a rule: uncertainty must stay attached to the estimate.
Once uncertainty is allowed to survive the meeting, the conversation changes. The team can talk about confidence instead of pretending. Product can talk about value instead of capacity alone. Management can talk about risk instead of control. The organisation can plan with its eyes open.
The work will still be uncertain. Software will still surprise people. Dates will still move. Some estimates will still be wrong.
But the wrongness will no longer be hidden behind theatre. It will become information, and information is what planning was supposed to create in the first place.
Footnotes
-
Schwaber, K., & Sutherland, J. (2020). 'The 2020 Scrum Guide.' Scrum Guides. https://scrumguides.org/scrum-guide.html ↩ ↩2 ↩3
-
McConnell, S. (2006). 'Demystifying the Black Art of Software Estimation: What Is an "Estimate"?' Microsoft Press Store. https://www.microsoftpressstore.com/articles/article.aspx?p=2191414&seqNum=3 ↩
-
Molokken, K., & Jorgensen, M. (2003). 'A Review of Software Surveys on Software Effort Estimation.' 2003 International Symposium on Empirical Software Engineering. https://doi.org/10.1109/ISESE.2003.1237981 ↩ ↩2
-
Jorgensen, M. (2004). 'A review of studies on expert estimation of software development effort.' Journal of Systems and Software. https://doi.org/10.1016/S0164-1212(02)00156-5 ↩
-
Buehler, R., Griffin, D., & Ross, M. (1994). 'Exploring the "planning fallacy": Why people underestimate their task completion times.' Journal of Personality and Social Psychology. https://doi.org/10.1037/0022-3514.67.3.366 ↩
-
Kahneman, D., & Lovallo, D. (1993). 'Timid Choices and Bold Forecasts: A Cognitive Perspective on Risk Taking.' Management Science. https://doi.org/10.1287/mnsc.39.1.17 ↩
-
Mahnic, V., & Hovelja, T. (2012). 'On using planning poker for estimating user stories.' Journal of Systems and Software. https://doi.org/10.1016/j.jss.2012.04.005 ↩
-
Hastie, S., & Wojewoda, S. (2015). 'Standish Group 2015 Chaos Report - Q&A with Jennifer Lynch.' InfoQ. https://www.infoq.com/articles/standish-chaos-2015/ ↩ ↩2
-
Little, T. (2006). 'Schedule estimation and uncertainty surrounding the cone of uncertainty.' IEEE Software. https://doi.org/10.1109/MS.2006.82 ↩
-
Duarte, V. (2015). '#NoEstimates: How to Measure Project Progress Without Estimating.' CreateSpace Independent Publishing Platform. https://books.google.com/books/about/NoEstimates.html?id=x_QXvgAACAAJ ↩
-
Linders, B. (2015). 'Q&A with Vasco Duarte on the #NoEstimates Book.' InfoQ. https://www.infoq.com/articles/book-review-noestimates/ ↩