Estimation as Decomposition
"This will take two weeks" is a feeling about a list you have not written. Break the store into product model, cart, checkout, payment, testing and deployment, estimate each with a range, and the number becomes something you can defend — and revise.
The situation, the reflex, and why it stalls
Every lesson starts where being stuck starts: someone has a problem, and the first move that comes to mind feels like progress.
Someone asks how long the store will take. What do you do before answering, and what makes the answer more than a guess with a unit on it?
The founder asks "so, roughly, how long?" and you hear yourself say "two weeks, maybe three". You have no idea where that came from. It felt about right, it was what they seemed to want, and now it is written in a message thread as a commitment.
Give a number that feels right, hedged with "roughly". It is fast, it answers the question that was asked, and it avoids the awkwardness of saying "I do not know yet". Pattern-matching against past projects is real information, so the number is not random — it just cannot say what it is made of.
The number exists and nobody, including you, can say what it contains. When the founder later asks "does that include the admin page?", the honest answer is that the number was not built from parts, so it does not include or exclude anything.
- The number exists and nobody, including you, can say what it contains. When the founder later asks "does that include the admin page?", the honest answer is that the number was not built from parts, so it does not include or exclude anything.
- Because it has no parts, it cannot be revised. Discovering that the payment provider forces a hosted checkout page does not change "two weeks" by a computable amount; it just makes the number feel wrong, and a number that feels wrong gets quietly replaced by "it is taking longer than expected".
- The estimate is dominated by the parts you can picture. You can picture product pages and a cart, so the number is sized for them; payment and deployment, which you cannot picture, contribute nothing to it and then take most of the time.
- A flat number carries no uncertainty, so it is read as a promise. The person who hears "two weeks" plans around two weeks. The person who says it meant "somewhere between one and five".
The move
Precisely enough to apply it to a problem you have never seen — not a slogan.
- Refuse to estimate the whole. Decompose it into pieces that are each small enough that you can picture building them — the same decomposition you would do to build it (Decomposing a Problem). If a piece cannot be pictured, it is not a piece yet; split it, or mark it as unknown and estimate the research, not the work.
- Estimate each piece as a range, not a point: the best case if nothing surprises you, the likely case, the worst case you would still call the same task. The width of a piece's range is a statement about how well you understand it, and it is usually more useful than its centre.
- Aggregate the pieces honestly. The sum of the likely cases is not the likely total — pieces surprise you independently, so the total is wider than any piece and narrower than the sum of every worst case. The point is not the arithmetic; it is that the total is now a range with parts you can point at.
- Attach the assumptions the estimate rests on — one warehouse, a provider you have used before, no guest checkout — so that when one changes, you know which pieces move (Making Assumptions Explicit). The estimate is now a model of the work, and models can be updated.
The number, taken apart
The reflex produces a total. The move produces the table below, and the total falls out of it. Read the width column first: it says where the estimate is soft, and it is the column a flat number does not have.
Payment is not the biggest piece by likely effort — it is the biggest by *uncertainty*, because nobody on this project has integrated this provider. That distinction is what the decomposition exposes and what the flat number hid.
| Piece | Best | Likely | Worst | Why the width |
|---|---|---|---|---|
| Catalog: product model, list, detail page | 2 | 3 | 5 | Built before; the width is image handling. |
| Cart with persistence | 1 | 2 | 4 | Anonymous-vs-account cart decision not yet made. |
| Checkout without payment | 2 | 3 | 5 | Validation rules are known; stock-at-checkout is not. |
| Payment integration | 3 | 6 | 15 | Never used this provider; hosted page vs API unknown. |
| Order persistence and history | 1 | 2 | 3 | Plain CRUD once the order shape exists. |
| Failure handling around payment | 2 | 4 | 8 | Depends on what the provider actually does on timeout. |
| Admin: products and stock | 2 | 3 | 5 | Familiar; width is auth and image upload. |
| Testing across the workflow | 2 | 4 | 6 | Payment test mode may or may not be scriptable. |
| Deployment and first environment | 1 | 2 | 5 | Depends on where; secrets and webhooks need a public URL. |
1flat: "about two weeks"2 3sum best: 16 days (~3 weeks)4sum likely: 29 days (~6 weeks)5sum worst: 56 days (~11 weeks)6 7aggregated: most likely 6-7 weeks; plausibly 4-108widest: payment (3-15) -> spike before committingThe likely total is three times the flat guess. That is not because the guess was careless — it is because the guess was made from the pieces that could be pictured, and those really do sum to about two weeks.
Where the width comes from
A piece is wide for one of a small number of reasons, and each reason has a different remedy. The board below does for the estimate what an unknowns board does for the problem: it turns "payment might take a while" into a question with an experiment whose answer would narrow the range.
Notice that the experiments are small. Narrowing an estimate does not mean starting the work; it means spending an afternoon finding out which of the plausible shapes the work has.
- ✓Catalog, cart and admin are shapes this developer has built; their ranges are narrow and their worst cases are about details.
- ✓The order shape is decided by the checkout decomposition, so orders and history are cheap once checkout exists.
- ~One developer, uninterrupted. Every range widens if that is not true.
- ~The provider has a test mode that can be driven from a script — assumed because most do; to be verified in the payment spike.
? Payment could take a while.
becomes Does this provider expect us to redirect to a hosted page, or to call an API and handle the confirmation ourselves — and which of those does the founder accept?
experiment Read the provider's integration overview for one hour and create one test-mode payment each way; note which one the confirmation flow requires.
? Failure handling is hard to size.
becomes When the provider times out after we have asked it to charge, does it tell us later, and how do we find out whether the charge happened?
experiment In test mode, request a charge and kill the request before the response; then query the provider for that charge and see what state it reports.
? Deployment always takes longer than you think.
becomes Does the provider need a public HTTPS URL to deliver confirmations, and do we have one before the deployment piece is done?
experiment Check the provider's confirmation mechanism in its documentation; if it needs a URL, move a minimal deployment earlier in the order.
Each experiment is smaller than the piece it narrows. An estimate with a wide piece and no experiment attached is a worry with a range on it.
Point estimate against range
The difference between the two answers below is not politeness. The flat answer commits to a number it cannot explain; the decomposed one commits to a model and lets the number follow. When the payment spike comes back with "hosted page only", the second answer changes by a known amount and the first just becomes wrong.
"About two weeks, maybe three." — Includes whatever the speaker happened to picture. Cannot say whether admin is in it. Cannot move when payment turns out to be a hosted redirect. Read by the listener as a promise.
"Nine pieces; most likely six to seven weeks, plausibly four to ten. The width is almost all payment, which I have not used before — I would like two days to spike it before we commit to a date." — Includes what it lists. Moves by a computable amount when a piece changes. Names the experiment that would narrow it.
An estimate is a claim about work, and a claim you can decompose can be checked, revised and argued with piece by piece. A flat number can only be believed or not.
How to do it
Most important first.
- Write the pieces before any number. If the list has fewer than a handful of entries for a system with several actors and an external provider, the decomposition is not done (Decomposition by Capability).
- For each piece, ask "have I built this exact thing before?" Yes narrows the range; "something like it" widens it; "never" means the range should include a spike to find out what the piece even is (Spikes).
- Write three values per piece — best, likely, worst — and resist the pull to make worst a polite version of likely. Worst is the case where the piece turns out to be two pieces.
- Include the pieces nobody asks about: testing, deployment, the first bug report, the admin page that "obviously" has to exist. These are missing from flat estimates because they were missing from the picture (The Requirements Nobody States).
- Show the list, not just the total. An estimate that can be argued with piece by piece is worth more than one that can only be accepted or rejected.
Worked on a concrete problem
The move has to produce something. This is what it produced.
- The store, decomposed for estimating: product model and catalog; cart with persistence; checkout without payment (validate, total, create order); payment integration; order persistence and history; failure handling around payment; admin for products and stock; testing across the workflow; deployment and a first production environment. Nine pieces where there had been one number.
- Ranges, in days, for a developer who has built catalogs and carts but never integrated this provider: catalog 2–3–5, cart 1–2–4, checkout without payment 2–3–5, payment 3–6–15, orders 1–2–3, failure handling 2–4–8, admin 2–3–5, testing 2–4–6, deployment 1–2–5. Payment's range is the widest by far, and that width was invisible in "two weeks".
- Aggregated: the likely cases sum to roughly six weeks; the best cases to about three; the worst to nearly eleven. The honest answer is "most likely six to seven weeks, could be as little as four, could be ten if payment goes badly" — and the founder can now ask which piece they would like to cut, because the pieces are on the table.
- The founder asks "what if we skip the admin page and I edit the database directly for now?" That removes one piece with a known range, and the estimate shrinks by a computable amount. The flat "two weeks" could not have answered that question at all.
How you know it worked
What now exists that did not before, and what question you can now ask.
- The estimate is a list with ranges, and the total is a range that you can explain from the list.
- The widest range points at the piece you understand least, and that piece has a spike or a research question attached rather than a hope.
- When scope changes, you can say which pieces move and by how much, instead of re-feeling the whole number.
- The stakeholder argues with pieces — "surely the cart is not four days" — rather than with the total, which means they are reading the model.
The questions you can now ask
The field this whole domain exists for. After this lesson, these are the questions to put to an unfamiliar problem.
- ?What are the pieces, and which of them can I not picture building?
- ?For each piece, what is the best, likely and worst case — and why is the worst case that wide?
- ?Which single piece contributes most of the uncertainty, and what small experiment would narrow it?
- ?What assumptions does this estimate rest on, and which pieces move if one of them is wrong?
- ?If the stakeholder wants it sooner, which piece are we removing, not which number are we lowering?
What can go wrong
- The decomposition becomes a work-breakdown structure with forty rows and hour-level precision. The ranges are now fake: nobody knows a task is 3.5 hours rather than 4. The move wants pieces small enough to picture, not small enough to schedule.
- Every piece gets the same range because the estimator is being fair rather than honest. The information in an estimate is the *difference* between the ranges; flattening them throws it away.
- The pieces are estimated and the list is thrown away, leaving only the total. Two weeks later nobody remembers what "seven weeks" included, and the estimate has become the flat number it was meant to replace.
- The move is applied to a task that genuinely takes an afternoon. Decomposing a one-line change into pieces is ceremony; the move pays for itself when the thing being estimated has parts you cannot picture.
- A decomposed estimate takes an hour to produce and a flat one takes a second; on a task with no unfamiliar parts, the hour bought nothing.
- A range is harder to plan around than a point, and some stakeholders will hear "six to ten weeks" and write down six. Communicating the range is its own piece of work (Communicating Uncertainty).
- Estimating the pieces means committing, early, to a decomposition — and the decomposition may be wrong in ways that only building reveals (Requirements Emerge During Implementation).
- "So estimates should be precise." No — they should be *decomposed*. A range of four to ten weeks built from pieces is less precise than "two weeks" and far more accurate. The slogan "estimates are always wrong" is falsifiable: a decomposed estimate whose pieces were each within their range was right, even if the point guess embedded in it was not.
- "Add a buffer to the total." A buffer is a flat number added to a flat number. The decomposed version already knows where the uncertainty is; a buffer smears it across pieces that did not need it and under-covers the one that did.
- "The decomposition for estimating is the decomposition for building." Usually, and that is the point — but the estimating one may include research pieces and deployment pieces that the building tree treats as outside the product. Keep them; they take time whether or not they are features.
Where this applies
Problem-solving advice is stated as universal far more often than it is. These labels say what each method is specific to — and where CONTESTED appears, the note gives the strongest form of the opposing view.
- GENERALDecomposing before estimating applies to any work with parts you cannot fully picture — a feature, a migration, a research task. For a task you have done many times, the decomposition is already in your head and the number is fine.
- TEAM-SPECIFICA solo developer estimates their own unfamiliarity; a team lead estimates other people's, and the ranges must widen for pieces assigned to whoever has not built that kind of thing before. The list is the same; the widths are not.
- ILLUSTRATIVEThe store, the nine pieces and every day-count in the worked example are invented to show the shape of the argument. Real ranges come from the people who will do the work, not from this lesson.
Where the depth lives
This domain asks the question and hands the answer off by name.