Estimates start with a design and end with a number. Appetites start with a number and end with a design.
What the graphic below shows are two very different ways of deciding how (and *how much*) work gets done:
1. **Estimate** (Fixed Scope, Variable Time)
- Here, you begin by locking down *everything* you want delivered—the full feature set, requirements, etc.
- Because that scope is fixed, the time (and cost) will vary. You might go over budget or stretch deadlines if the project (e.g., a product feature) takes longer than expected.
- This approach leads to detailed “how long will it take?” estimates up front, which can be notoriously off-target in software projects unless there are 0 unknowns left or you are doing something for the 10th time and there’s minimal variability in the task.
2. **Appetite** (Fixed Time, Variable Scope, i.e., time budgets and talent allocation (number of people and their domain experience levels))
- Instead of guaranteeing *all* possible features, you fix the amount of time you’ll spend—say, six weeks (ideal max time to spend at a time).
- Once you have a narrow problem or opportunity defined, you ask yourself: “How much time is it worth spending on this?”.
- Then, you shape the project or projects to fit within the Appetite’s time budget, focusing on a *reduced* set of must-have work.
- While shaping (not building), if something looks like it would blow the time budget, you cut or simplify that piece so you can still ship on time. You estimate up to a defined constraint, the outermost boundaries, i.e., the Appetite. This is much like you do when planning a vacation, and you know you have, e.g., one week to fill up.
- You also use this time budget to guide the development cycle. So, an Appetite is a constraint on planning and building. If you are going to have overruns into the post-launch period (like a cool-down week), ask if there are too many unknowns vs. knowns left. If there are going to be too many unknowns at the end of the budget, consider not giving in to the sunk cost fallacy and asking if this needs to be reshaped or paused for another reason. Preserve optionality!
Why **order-of-magnitude estimation** might not be all that helpful in the “Appetite” (time budget) model:
- When you fix time (e.g., “We have six weeks”), it’s no longer about whether a feature is a 2‑week or 10‑week project in a broad sense; you already know your total runway is six weeks at a time.
- If an idea looks too big—even an “order of magnitude” bigger than you can handle in six weeks—you’re going to cut or reshape it immediately. There’s no real need to fine-tune whether it’s “two or three times bigger” because you’re not going to expand the six-week window. You’ll only ever shrink or simplify the scope.
- In other words, the *exact* size of the project (even if “big” vs “huge”) isn’t as relevant because you don’t flex the schedule—you flex what you build. Once it’s clear it won’t fit in six weeks, you don’t proceed as-is; you reduce the scope or abandon parts of the idea.
This is why, in a fixed-schedule (Appetite) approach, deeply detailed or large-scale estimates add limited value. You’re less concerned with nailing down precise guesses and more focused on shaping the scope to meet your fixed time constraint.
Here’s another way to understand the Appetite.
There isn’t “one” Time Budget for a project. That would presume that the project is already defined.
Instead, think of how we might consider three different Appetites for the project:
If we only had two weeks, we’d hack it in like this…
If we had six weeks, we’d include this, that, and this other thing…
If we had six months, we’d rewrite that existing service and redo it like this…
Presenting a set of options like this creates contrast and helps decision-makers better see the trade-offs and opportunity costs. Then the Appetite isn’t a different word for an estimate. It’s a decision about how to constrain the types of conversations we are willing to have about something. It is not a question of small, medium, or large; it is about making trade-offs and deciding what is in and what is out.
Sometimes there is deeper work or a feature that has too many moving parts that prevent it from being scoped down to one six-week project (like 6 weeks). Even in that case, we scope off the work in such a way that each cycle is expected to be done so that when the next cycle starts, it is just the other parts of the work that were scoped off separately or orthogonal to the parts of the previous cycle(s). We then integrate and ship altogether at the appropriate cycle (different for each project). Because we have a hard time wall to avoid sunk costs, and cycles are not long, prioritizing "the wrong thing(s)" is not too big a deal.
The value here is that one important part of a larger product was designed, implemented, demoed, and settled. The team can feel good about showing tangible progress, even if only the first cycles are shipped internally. And the team and management both felt confident in the overall direction by seeing working pieces more frequently.