---
title: Estimation Theater
synced_from_vault: true
vault_source: 03-living-docs/patterns/Estimation-Theater.md
public: true
type: pattern
tags:
  - pattern
  - process
  - anti-pattern
  - sprint-planning
---

## Core Concept

A sprint planning ritual where the team estimates tickets one by one without connecting estimates to capacity, priorities, or what should be cut. The ceremony of estimation (simultaneous reveals, brief discussion, consensus) creates the *feeling* of rigor without the *substance* of commitment. The sprint fills up additively — everything goes in, nothing comes out — and the resulting backlog is a wish list, not a plan.

## The Pattern

1. **Tickets presented sequentially.** Each ticket gets a brief explanation and a "3-2-1" simultaneous point estimate. No one asks "should we do this at all?"
2. **No capacity check.** Points accumulate without comparison to team capacity or historical velocity. The total is noted at the end as trivia, not as a constraint.
3. **No prioritization filter.** Strategic goals may be shown but aren't used to cut scope. Every ticket implicitly has equal priority because it made it onto the board.
4. **Scope creep during estimation.** Discussion of a ticket's requirements balloons into design debates, process questions, and scope expansion — the opposite of what estimation should do.
5. **Large audience, low participation.** 10-15 people on the call; 2-3 are relevant per ticket. The rest sit idle, burning expensive engineering time.

## Why It Matters

Estimation Theater produces a sprint that looks planned but isn't committed to. When everything is priority, nothing is. Engineers leave the meeting without clarity on what matters most, so they default to whatever's most interesting or most recently discussed. When the sprint inevitably doesn't finish, there's no accountability because there was never a real commitment — just a pile of estimated tickets.

**The deeper problem:** Estimation Theater is a symptom of missing prioritization at the leadership level. If leadership hasn't decided what's most important, the team can't either, so they fill the void with process.

## What Good Looks Like

- **Capacity-first:** Start with how many points the team can realistically complete (based on velocity), then fill to that limit and stop.
- **Prioritized, not sequential:** Rank tickets by importance. The team commits to the top N that fit capacity. Everything else is explicitly deferred.
- **Small room:** Only the people who need to discuss a ticket are in the estimation meeting. Broadcast the sprint plan afterward.
- **Time-boxed estimation:** If a ticket needs more than 2 minutes of discussion, it's not groomed enough. Pull it out.

## Related Patterns

- [Prioritization-Reveals-Leadership](/patterns/prioritization-reveals-leadership) — inability to prioritize is the root cause of Estimation Theater
- [Process-vs-Objective](/patterns/process-vs-objective) — Estimation Theater is process-focus without objective-focus
- [Effectiveness-Over-Efficiency](/patterns/effectiveness-over-efficiency) — estimating efficiently what shouldn't be done at all
- [Busy-vs-Productive](/patterns/busy-vs-productive) — the team feels productive because the meeting was long and detailed
- Shadow-Matrix — sprint planning becomes theater when its inputs are seven unreconciled authority streams

---

## Cross-References

