Estimating software tasks and stories: avoid time-based estimates

I was recently asked what I thought of using time-based estimates when tracking software tasks.

TLDR: I think it’s a terrible idea that can hurt your software by introducing bugs and burning out developers.

I think using time-based estimates is pretty toxic. It leads to people being “held accountable” i.e. pressured and/or expected to work long hours to meet the “estimate”, which magically morphs into a target. This makes developers rush, causing bugs and missed tests and hygiene tasks, which ALWAYS come back to bite you, and always earlier than you expected. It also makes developers stressed and tired, which makes them write worse code.

These problems are almost impossible to avoid, even if the manager deliberately never mentions estimates! It’s just human nature to feel you should stick to your estimate.

Instead, I advocate relative units (e.g. “story points”). These can be used for prediction because you can look at past work to see how long an average story point takes, but they don’t come with the baggage that your prediction will be spot on.

Note: to bootstrap this process, you will need to compare new work with things you have already done. Get a feel for how complex an old task was, and choose an arbitrary amount for that task. Now estimate new tasks by saying e.g. “that feels about twice as complex as X”. This also allows you to bootstrap your prediction process because you can see how long that old task took to complete.

In either case, I also advocate for a ranged estimate (low-high). When predicting, I always take the high.

It’s also really important to work as a team to estimate, not do it individually.

Another rule: only the people who implement the task do the estimates. This prevents two antipatterns: 1. someone who has no skin in the game thinking it’s going to be easy without really engaging with the problem, and 2. a manager or person in authority who wants to try and make it go faster by estimating low. This NEVER works, and instead makes your developers stressed.

If there is disagreement or the range is wide, either just make it high (if the story is not going to be done soon), or take the time to figure out why people disagree or are uncertain. This always pays off, and it means taking the high end when you predict doesn’t result in inflated estimates.

Further reading: Martin Fowler: Purpose of Estimation