Estimation Basics

Estimates are not promises

An estimate is a prediction under uncertainty. A target is something you want to hit, and a commitment is something you agree to deliver. Mixing these up causes pressure and mistrust. Say which one is being discussed.

Why estimates go wrong

• Unknowns hide work: unfamiliar code, vague requirements and new technology.
• People tend to imagine the best case and forget testing, review, deployment, meetings and interruptions.
• Waiting for other people or systems adds delay.
• The task grows while you work on it (scope creep).
• The first number mentioned sticks, even if it was a casual guess (anchoring).

Common ways to estimate

• Hours or days are intuitive, but easily mistaken for a deadline.
• Story points give a relative size for a story, compared with others the team has done. Teams often use values like 1, 2, 3, 5, 8. The team’s velocity (points finished per sprint) can then be used to forecast. See Agile, Scrum, and Kanban.
• T-shirt sizes (S, M, L) give early rough sizing.
• In planning poker, team members estimate separately, then discuss differences. The discussion often matters more than the number.
• Ranges tell the listener more: “three to six days” says more than “four days”.

Making an estimate better

1. Break large work into smaller pieces, which are easier to size.
2. Clarify the requirement first. See Requirements and User Stories.
3. Compare with similar past work.
4. State assumptions and risks with the number.
5. Use a time-boxed investigation (a spike) when the unknowns are large.
6. Update the estimate as you learn, and say so early.

Try it

Pick three small tasks you finished recently. Without looking at your records, write the effort you would have estimated, then check how long each really took. Note where you were off and which hidden work (review, setup, waiting) you missed.