Estimating is difficult. Estimating software development is even harder.
We all miss estimation targets. We miss at estimation, but also when delivering on time.
Here’s what you can do to improve the software estimates.
Look at previous tickets
Track time. Track time on previous tickets. Use this as a reference point.
Make a map of tickets. Map of story points to tickets. Here’s an example. Refer to this when making estimates.
Take time to process tickets
Estimates given at the coffee machine will (like the coffee) come back to haunt you. — The Pragmatic Programmer: From Journeyman to Master 1st Edition
Estimate with different precision. Days are not enough? Give estimates in weeks and months.
Give rough estimates. Missing the mark then doesn’t look so bad with rough estimates.
http://www.agilenutshell.com/cone_of_uncertainty
Determine the scope. Understand the domain first. Know exactly what needs to be done. Do proper research.
Break the task down. Tasks exceeding one sprint can be decomposed. Build estimates on decomposed tasks.
Add contingency points, to cover the errors and unknowns. You’re not sure about an estimate?
Create a spike.
Investigate. Build proof of concept, if possible. Estimate after PoC.
More people working on tasks causes more friction. More communication, synchronization, and work are needed.
You never have two same tasks. If they were the same, nothing to work on. Tasks differ. Differ in the personnel, requirements, and priority.
Key points to include when estimating:
- Days off
- Communication between teams
- Testing
- Design updates
- Changelog updates
Rely on team knowledge
Use planning poker. Consensus-based estimation. Everyone gives high-level estimates, and everyone should agree.
Fibonacci sequence is used for estimations. There’s no way of doubling the estimates. There’s no way of cheating the system.
After voting, estimators explain their votes. The highest and lowest estimates go first.
Planning poker improves team coordination. The discussion takes place, and everyone participates. With this technique, the focus comes on code quality.
This technique is lightweight. There’s no anonymity, but interaction improves. The only overhead is meetings, refinements, and grooming sessions.
Scrum poker combines knowledge. Combines knowledge both from juniors and seniors. Whole team knowledge is there when estimation takes place.
What to avoid?
Don’t estimate under pressure. There can be pressure from peers, businesses, or other factors.
You’ll never give a good estimate under pressure.
You’re either going to give a low estimate, to satisfy the pressure. You won’t go for the higher one, since you’ll feel embarrassed.
Don’t look into tickets with dependencies. Estimate tickets from the bottom up. Contingency always fails to compensate for the unknowns.
Don’t estimate ambiguous tasks.
Don’t give estimates before talking with a domain expert. This can be senior in your team, or business analyst.
Don’t estimate every ticket. There’s no need to estimate bugs. Sometimes they take too little, sometimes a lot. Effort spent on estimating bugs is useless.
Don’t estimate non-essential tasks. Estimate critical ones.
Estimates are just a way to communicate — Deadlines And Estimates In Startups
Don’t be certain about estimation. There’s no way to forecast software estimations. Don’t give percentages of confidence when estimating.
Sometimes you don’t meet the estimate. Inform your scrum master about it. Inform on time. Not before the sprint ends.
Conclusion
What can you do to improve estimation?
- Take note of previous work
- Operate on team knowledge to tackle estimation
- Use contingency to make better estimates
- Prefer face-to-face conversations when estimating
- Over-estimate
- Don’t under-estimate, leave your ego at home
- Don’t be certain, it’s an estimate
- Avoid estimating non-granular tasks
- Avoid estimating tickets with dependencies
Resources
Software development cost estimation approaches — A survey Barry Boehm, Chris Abts, and Sunita Chulani
How to respond when you are asked for an estimate?
Richard Clayton - Software Estimation is a Losing Game
Top comments (0)