Known path works, few surprises.
loading…
The estimate should be easy for another engineer to inspect and challenge.
Estimate Quality ≈
Scope Clarity × Decomposition Quality × Risk AwarenessBreak the delivery model into work, separate evidence from guesswork, and produce a range. If the estimate cannot be explained, it cannot be managed.
| Type | Example | How to handle |
|---|---|---|
| Known | Create a standard authenticated dashboard | Estimate from experience |
| Known unknown | Can the payment provider support the refund rules? | Research or technical spike |
| Unknown unknown | Unexpected vendor limitation | Use contingency and early integration |
Early in a project, “21 working days” is usually invented precision. “Three to five weeks” is more honest, provided you can explain what keeps the work near three and what pushes it toward five.
Known path works, few surprises.
Normal rework, review, and integration issues.
A major assumption fails or scope expands.
Uncertainty should decrease as the team learns and integrates.
A usable estimate For one experienced engineer, the MVP is approximately three to five weeks, assuming we use hosted authentication, a hosted payment checkout, and an existing design system. A production pilot is approximately six to eight weeks. The largest uncertainties are refund rules and physical-access integration.
Do not defend an old number after its assumptions have failed. Re-estimate after the first integration, after a technical spike, when scope changes, or when the delivery level moves from demo to pilot.
Explain why the number changed “The estimate changed from four weeks to six because the new requirement adds custom authorization and a migration. Here is the added work and the available trade-off.”
A defensible estimate A good estimate is not a confident number. It is a range with visible assumptions and risks.