Estimation is Haruspication (and Management Makes It Prophecy)

"Ten easy steps to create an enemy and start a war"
— Anti-Flag (Anatomy of Your Enemy)

Mark,

I watched someone on my team update a Jira story estimate. "5" went into the points field. No conversation. No planning poker. No fibonacci debate. Just 5. They examined the app's entrails so many times they know what they'll find.

The team are experienced haruspices. Each one has learned to read the signs of the work's complexity. But management never witnesses the ritual. They just hear "5" as a prophecy. Your divination becomes their commitment.

I've seen this before. I know what happens next. History may not repeat, but it does rhyme.

The Ritual

What I observe: Product Manager opens a story. Describes it briefly. Calls on someone: "I think you should handle this one. What do you think?"

The answer: "3."

How this looks: Efficient. Respectful of everyone's time. No need to drag the whole team through planning poker when one person will do the work. The PM knows who to ask. The developer gives a quick read. Move on.

This seems reasonable: Why waste an hour on planning poker when you can get the same number in thirty seconds? The developer examined the work, made their assessment, declared "3." That's the haruspication done.

What the number is: That "3" is the developer's read on the app's entrails for the purposes of this specific user story. Three... somethings. Points. Units. Whatever the team calls them. It doesn't represent anything concrete, it's the divination of the codebase's complexity for implementing this specific user story by this specific developer.

What I can't see: Whether this number will means anything to anyone else. Whether anyone will remember why it was "3" versus "5." Whether it's calibrated against anything. They're usually right. I can't explain why. I can't even explain the estimate.

What I know: The number goes into Jira. What happens next is universal.

The Extraction

The distance: The rest of the company doesn't witness the ritual. They're not in the meeting where the PM asks and the developer answers. They don't see the developer pause, think, examine a mental model of the app's complexity. They don't see any hedging. They don't see nuance. They just open Jira later and see: Story #1247 - 3 points.

The data point: For the rest of the company, that "3" is raw data. Clean. Objective. A measurement. They didn't witness the haruspication, they don't know it's a messy divination.

The translation: Three what? The team might have an understanding. Three units of complexity. Three relative-to-those-other-stories. Three fibonacci-adjusted somethings. Or maybe they don't have an agreement. Maybe "3" means different things to different developers. For the team it's "3." And it works.

They don't care: The rest of the company needs to convert "3" into something usable. Three points. How many points per week does this team do? If they average 15 points per sprint, then "3" is... two days? A fifth of a sprint?

The interpretation becomes fact: The company performs its own divination on your divination. They're making a prophecy from something they never witnessed. And their interpretation - "3 points = 2 days" - is baked into the Gantt chart. Gets communicated to stakeholders. Informs a delivery date.

Your coordination ritual became a prophecy for delivery.

The Prophecy

The meeting you weren't in: The ask comes, when will feature X ship. Someone opens Jira: Epic #123. Story #1247 - 3 points. Story #1248 - 5 points. Story #1249 - 8 points.

The conversion: They look at the grab bag of numbers, the velocity number, and think "this is about two weeks."

No math: They didn't add them up. They didn't calculate velocity. They just... looked at the shape of it. The feel of it. Three, five, eight. Yeah, two weeks sounds right.

You never said that: None of the developers who said "3" or "5" or "8" ever said anything about weeks. They gave relative complexity assessments - probably with hedges, possibly unstated even to themselves. "3, assuming the API works like I think it does." "5, unless we hit that weird state management issue again." "Probably 5, but I've never touched that part of the code so 8." All of that nuance might have lived in their heads when they said the number. Or it might not have. The team discussion may or may not have happened. Outside of the team, nobody knows.

The prophecy is declared: "If Epic #123 starts by March 1st it'll ship on March 15th."

The prophecy becomes: "Epic #123 will be in production on March 15th."

Every hedge gets stripped away: The conditional - "if it starts by March 1st." The developer's uncertainty - "assuming the API works." The complexity - "unless we hit that state management issue." The unknowns - "I've never touched that code." All discarded. What's left is absolute: March 15th.

The automatic divination: Three haruspications, each wrapped in possibly unstated caveats, got eyeballed into a delivery date that sounds like certainty. The developers who gave those estimates have no idea their qualified divinations became binding prophecy.

When March 15th comes: The epic isn't done. Maybe the API didn't work like they thought. Maybe they hit that state management issue. Maybe the unfamiliar code was worse than expected. Maybe it didn't start March 1st. Doesn't matter.

The trap: "Why are we late?" Nobody estimated March 15th with certainty. Someone looked at a grab bag of deeply nuanced numbers and felt it was two weeks, if all goes right. The team gets blamed for a false prophecy they never made.

"Have the media broadcast only the ruling party's information"
— Anti-Flag (Anatomy of Your Enemy)

The Trap

Here's what I understand: Product doesn't care about complexity. They shouldn't. Product cares about timelines. The company needs coordination. Marketing needs to know when to plan campaigns. Sales needs to know what to promise customers. Everyone needs some sense of when they can do their jobs.

The legitimate need: Timelines help organizations synchronize. Without them, nobody knows what's coming or when. Product can't plan releases. Marketing can't prep launches. Sales can't set customer expectations. The business needs predictability to function.

The mismatch: Story points can't give them what they need. They're not designed for that. A developer's thirty-second haruspication of relative complexity exists to explain this ticket may take longer than that ticket. The grab bag of numbers that helps the team coordinate work internally becomes meaningless when eyeballed into a timeline.

What's actually happening: The company is using complexity divination for project planning. They're treating the team's internal coordination ritual - these quick complexity assessments - as if they're precise measurements that can be mathed into a schedule.

Everyone's doing their best: Product needs timelines, they use what's available. The team estimates in story points because that's how it's always been done. The company converts those points into dates because they don't have anything else. Nobody's being malicious. Everyone's trapped in a system that doesn't work.

The actual trap: The team has been trained to give numbers. Product has been trained to convert them. The Gantt charts already exist. The prophecies are already being declared, and mistrusted. The trap is already set, and my team has been burned by it before.

And I've seen this before: I know how it ends. The team will get blamed for false prophecies they didn't intend. Trust will erode. The ritual corrupts everyone's goal of getting good software in front of users.

For Mark

The present reality: The team knows how to give numbers. Product knows how to convert them into timelines. The Gantt charts exist. The trap has gone off before. The trap is set, again.

The rescue mission: They've been trained to take the abuse - give a number, get blamed when reality doesn't match the prophecy. I need to undo that. What if I don't have the trust yet to break the trap?

The questions:

• Someone's going to ask how many points equal a week. They've already asked "when will it ship?" What do I say to protect the team without being uncooperative?
• How do I have the Gantt chart conversation when Product legitimately needs timelines and I can't yet offer them an alternative?
• What do I build first that buys me the time and trust to disarm the trap?

Estimation is haruspication. Management needs a prophecy. Everyone's trapped.

How do I get us out?