Time Estimation: Cookbook for Developers

Are you good at time estimation?

Myers–Briggs Type Indicator

Wikipedia (en)

Why again

• To sell your time to a client
• The list of tasks should be known
• To plan your or other's work

Types of estimation

• Preliminary estimation — high-level estimation
• Accurate estimation — low-level estimation
• Revaluation of timings — something has changed (specifications, team, etc.)

Common mistakes

• People do mistakes
• Lack of information or insufficient list of tasks
• Risks are not included
• It's hard to estimate new things: technologies, third-party API, etc.
• Every developer is good (and bad) at something
• Low personal responsibility

Step 0. Track your time

• The 20 Best Time-Tracking Apps (article)

1. Make everything clear

• Ask questions
• Find all bottlenecks
• Give best and worst estimations instead of an exact number

2. Be more detailed

• Decompose high-level tasks
• Think of the (exact) implementation
• Do not decompose everything

3. Think together

• Assign time estimations to a few developers
• Do time estimation reviews

4. Make risks visible

• Disclose a particularly unpredictible tasks
• Every member of the team should be aware of all risks
• Do research before implementing 'unknown' tasks
• Don't forget about timing revaluation

5. Do not forget about youself

• Remember, you don't spend 100% of your working hours on coding
• Reading docs, API refs, etc.
• Deploy, git, code reviews
• Testing
• Meetings
• Learning
• Coffee/cookies, emails, small talks, procrastination

6. Re-think your timings

• Confirm an estimation before you start to work on the features
• Discuss excact implementation with the team

7. Scream when it's crucial

• Don't be afraid of asking for help
• Inform your team/PM/client about time issues as soon as you get the idea you'll have them
• Team/PM/client are humans and you could convince them to make a different decision/timings/etc.

8. Analyze your work

• Time estimation is not about predictions
• Gather your experiense and analyze estimated and logged time
• Do "retro" on over- and underestimated tasks
• Calculate your index of estimation errors

Index of estimation error

Bonus. PM's tips

• Improve communicative skills (yours or/and your team)
• Motivate your team to learn how to estimate
• Try to group people in the office by some attribute (departments/projects)
• Implement different development methodologies (waterfall, agile, extreme programming)

What's next?