1. Is the expected outcome clear?
Before estimating implementation, make sure you understand what "done" means.
Check:
- Is the business objective clear?
- Is the expected behaviour described?
- Are acceptance criteria available?
- Are important edge cases known?
- Does everyone involved expect the same result?
If the outcome is unclear, confidence in the estimate should immediately decrease.
If the missing detail could change the solution, use the task readiness checklist before assigning a planning value. This checks one ticket; project readiness is a separate decision about the wider delivery setup.
2. Is the scope contained?
Ask whether the task is truly one task.
Warning signs include:
- several unrelated changes,
- frontend and backend work bundled together,
- infrastructure changes hidden inside a feature,
- data migration,
- new integrations,
- undefined follow-up work.
A task that contains several separate workstreams is usually easier to estimate after being split.
3. How familiar is the work?
Check whether the team has worked with:
- this codebase,
- this technology,
- this integration,
- this client,
- this business process.
Familiarity does not always reduce effort, but it usually reduces uncertainty.
4. Are there external dependencies?
Look for:
- third-party APIs,
- external vendors,
- client-provided content,
- access credentials,
- infrastructure teams,
- approvals,
- other development teams.
A dependency may not add implementation time directly, but it can create waiting time, uncertainty or rework.
5. What needs to be tested?
Do not estimate development and forget delivery.
Consider:
- functional testing,
- regression testing,
- responsive testing,
- browser testing,
- integration testing,
- client acceptance,
- deployment verification.
Testing effort should reflect the potential impact of the change.
6. Can the change affect existing functionality?
A small code change can still have a large blast radius.
Ask:
- Does it modify shared logic?
- Does it touch authentication or permissions?
- Does it affect payments?
- Does it modify existing data?
- Does it change a shared component?
- Is rollback difficult?
The larger the potential impact, the more care should be included in planning.
7. How likely is rework?
Consider:
- incomplete brief,
- unclear decision maker,
- multiple approval rounds,
- evolving design,
- uncertain business requirements.
If rework is likely, acknowledge it instead of pretending the first implementation will be final.
8. What do we still not know?
This is often the most important question.
Write down the unknowns.
If several major questions remain unresolved, consider estimating discovery first rather than pretending the implementation itself can already be estimated accurately.
Quick rule
A strong estimate does not require every detail to be known.
It requires the team to understand:
- what is known,
- what is risky,
- what is uncertain,
- how much confidence they have in the result.
For the method behind these checks, read the practical estimation guide. If the estimate supports an imminent start, continue with the project kickoff checklist.