Principle
Estimate approvals and integration as deliverables
A feature is not delivered when only its middle is done.
When it fits
- The implementation is estimated, while review, approval, import and verification are treated as administrative afterthoughts.
When to avoid it
- Some approvals are outside the delivery team's control; include them as dependencies without inventing control.
Why it matters
Treat required approval, integration, deployment, validation and handoff as work packages with owners and dependencies. They may contain little build effort but substantial elapsed risk. Include them in the done definition when the outcome depends on them.
An example
'Code complete' is not the delivery estimate when transport, business validation and production confirmation are still required.
Check your result
The forecast ends at the actual usable outcome, not at the team's favorite internal milestone.
Keep this limit in mind
- Some approvals are outside the delivery team's control; include them as dependencies without inventing control.
Connected ideas
Useful withPut the slow external dependency on the forecast
Evidence and sources
IPA cost-estimating guidance recommends documenting assumptions and representing uncertainty with reasonably optimistic, most-likely and reasonably pessimistic positions where appropriate.
Three-point estimates are inputs to judgment or modelling, not proof of a probability distribution.
Cost Estimating Guidance · Estimate ranges and assumptions
IPA guidance notes that uncertainty and estimate range depend on the maturity and variability of input data, so estimates should evolve as design and evidence mature.
A later estimate can still be wrong; maturity narrows uncertainty only when real information has improved.
Cost Estimating Guidance · Estimate maturity and range