Estimation is hard. Estimating well is an art. And missing your estimates as a team is called a failed sprint.
Why estimation is essential
Estimation in an agile context is not about predicting the future with precision. Its purpose is to let the team plan its sprints, compare the relative size of tickets and surface uncertainty.
A good estimate is mostly useful to ask the right questions before starting to code.
What to consider
You don't only estimate duration. You evaluate the overall complexity of a ticket, which combines several dimensions:
- Technical complexity (algorithms, architecture, integrations)
- Volume of work (amount of code, tests, documentation)
- Risk and uncertainty
- Dependencies with other tickets or teams
Steps of a good estimation session
- Make sure the ticket is detailed enough and understood by everyone.
- Clarify the acceptance criteria: without them, you're estimating in the void.
- Identify risks and grey areas before voting.
- Vote (Planning Poker or another method), discuss the gaps, vote again if needed.
- Split tickets that are too big (> 13 points) into more digestible pieces.
Classic mistakes to avoid
- Estimating in hours or days from the start
- Letting one person estimate for everyone
- Forgetting tests, code review, documentation
- Accepting a ticket without clear acceptance criteria
A poorly estimated ticket isn't a fault. A ticket estimated when the team doesn't understand what they're estimating is a problem.
