Estimation Is a Trap: How to Plan Engineering Work Without Story Points

Every Agile engineering manager I've met swears by story points. Then I ask: "On a scale of 1–8, how confident are you in your estimates?"

Usually, they laugh. Nobody's confident. The estimates are theater.

Story points are supposed to decouple estimation from time. But they don't. They create a different problem: you're spending two hours debating whether something is a 5 or an 8 instead of two hours building it. You're treating estimates as commitments ("We committed to 40 points this sprint," which is ridiculous because you can't control complexity). You're using estimates to measure productivity, which turns productivity into a video game where you keep inflating point values.

After 15 years of watching this in the wild, I'm convinced: estimation is a trap. Not "bad estimation," but estimation itself. The whole frame is wrong.

There's a better way. It's called appetite-based planning, and it comes from Shape Up.

The Problem With Estimation

Let me be specific about why estimation fails:

Estimation assumes certainty about unknowns. You sit in a room and estimate how long it'll take to build a feature you've never built before. You're not predicting time; you're guessing. The more guesses you average, the guesses get more confident, but they're still just guesses.

Estimates become commitments. The business hears "This is an 8-pointer, so we'll ship by Friday." Then actual complexity is higher, and you miss the deadline. You're blamed for "missing the estimate," even though the estimate was always a guess.

Estimation optimizes for looking right, not being right. If you estimate conservatively (big buffers), you look slow. If you estimate aggressively, you look fast until reality hits. Teams learn to game the system: inflate estimates, undershoot, look like heroes.

Estimates hide the real problem. A feature takes longer than estimated because the requirements were unclear, the tech stack is unfamiliar, or there's a dependency you didn't see. Instead of surfacing that as a team problem, you just mark it as a "missed estimate."

Estimation incentivizes scope creep at the margin. "Well, we estimated 40 points this sprint but we're only at 32. Let's add this other thing." You're not adding it because it's important; you're adding it because you have "room" in your estimate.

The second-order effect: estimation makes planning feel safe. You're committed to a plan based on guesses. When reality doesn't match the plan, you blame the execution instead of the plan.

Shape Up flips this. Instead of estimating work, you set an appetite.

Appetite-Based Planning: The Pattern

Here's how appetite-based planning works:

You define an appetite first. Not an estimate. An appetite. "We're willing to spend one engineer-week on this. No more."

Appetite includes a deadline. "Shipped by end of quarter." Or "in this cycle." This forces prioritization. You can't do infinite work; you have a fixed time box.

The team figures out what fits in that appetite. Not "How long will this take?" but "What can we deliver in one engineer-week that solves this problem?"

This flips the question. Instead of trying to predict duration, you're asking: What's the minimal valuable thing we can ship in the time we have?

If something doesn't fit, you descope. You don't ask for more time. You ask: What can we remove? Which edge cases can we defer? What's the MVP?

Appetite is fixed; scope is flexible. This is the opposite of traditional project management, where scope is fixed and duration is flexible.

A Concrete Example: The Feature That Saved Two Months

I worked with a product team building a new analytics dashboard. Under story points, it was estimated at 55 points—probably three weeks of work. But the product roadmap was tight. We needed this sooner.

So we set an appetite: two engineer-weeks. Two engineers, one week each. Ship something useful by Friday.

Instead of debating the estimate, we asked: What analytics matter most to users? What's the minimum viable visualization? We shipped:

Revenue trend chart (one week to build)
Cohort retention table (defer to next cycle)
Drill-down capabilities (too complex, skip)
Export to CSV (too much, skip)
Custom date ranges (nice-to-have, skip)

One week. Shipped. Users loved it. Six months later, they'd invested maybe another week to add features. Under story points, we'd have spent three weeks upfront building all of it.

The key insight: appetite forces ruthless prioritization. Estimation encourages scope inflation.

The Counterpoint: Appetite Planning Doesn't Work For Everything

Appetite-based planning is brilliant for shipping features. It's not a complete planning system.

It requires clear ownership. Someone has to decide the appetite and stick to it. If stakeholders are constantly moving the goal posts, appetite-based planning falls apart.

It needs team stability. If your team is churning engineers or people are constantly getting pulled to other projects, appetite-based work becomes impossible.

It requires a strong product person. Someone has to scope the work tightly and make ruthless cuts. If you don't have that, you'll overshoot the appetite.

It doesn't work for infrastructure work or refactors. "Refactor the database layer in one engineer-week" might be unrealistic. You might need a longer runway. Appetite works when you can descope; it doesn't work when technical work is binary (done or not done).

It assumes your tech stack is stable enough to predict costs. If you're in a brand-new codebase or dealing with a lot of unknowns, you might need some upfront estimation/research to set a realistic appetite.

This is why I don't say "Never estimate." I say: "Stop using estimation as your primary planning tool."

The Hybrid Approach That Actually Works

Here's what I recommend for most early-stage companies:

For feature work: Appetite-based planning. Set a time box. Descope ruthlessly. Ship within the appetite.

For new technology or infrastructure: Light estimation. Do a one-day spike. Figure out the unknowns. Then set an appetite. "After research, we think this is a 2–3 engineer-week bet."

For dependent work: Order it by risk and dependencies, not by estimate. "First, make the API backwards-compatible. Then, migrate the old clients. Then, deprecate the old endpoint." Don't estimate the whole thing; do it in bets.

For roadmap planning: Don't estimate. Count your bets. "In Q2, we can ship four features of this size or two features of that size." Use historical velocity (how many bets you shipped last quarter) to guide next quarter's roadmap.

For hiring/resourcing decisions: Use historical appetite data, not estimates. "The last three analytics features took 2, 1.5, and 2.5 engineer-weeks each. With 10 engineers in Q2, we can probably land 12–15 of these bets."

This is much simpler than managing a complex estimate system. And it's more accurate because it's based on historical data, not guesses.

Where I Come In

I've replaced story points with appetite-based planning in five companies. Each one reported that planning became faster (fewer meetings), more accurate (fewer "missed estimates"), and shipped more features per quarter.

If you're drowning in estimation overhead or your story points system has turned into a productivity-measuring tool that's harming your team, I can help you design a better planning system.

I'll audit your current process, identify where estimation is wasting time, and build an appetite-based planning framework that scales with your team.

Let's talk about it.

Action Checklist

Look at your last three shipped features. How long were they estimated? How long did they actually take? What was the miss rate?
Count how much time you spent in planning meetings in the last month. Multiply by loaded cost. That's your estimation tax.
Pick one small feature for next week. Don't estimate it. Instead, set an appetite: "Two days, one engineer. Ship something useful."
Build it within that appetite. Descope if you have to. What did you learn?
Run a retro with your team: "Is story points serving us, or are we serving story points?"
If points are overhead, propose a pilot of appetite-based planning for one cycle.