How to become better at task estimation

One of the tasks when writing software, give an estimation of how much a certain feature is going to take to implement. For the Product Owner or project leader or some other internal customer, it will define which features he or she will get within an amount of time. So it will help the product owner with his or her decision-making, whether the feature must be in the upcoming sprint or not.

We can also determine the velocity with a software estimation, creating a commitment for the team to meet the sprint goals. By knowing how much a task is gonna take to implement, we can put that number of tasks within a sprint which can be handled by the team. Not meeting sprint goals will bring the team into a negative emotional state: “whatever we do, we don’t make it this sprint”. So, people won’t even try their best to meet the sprint goals.

Task estimation seems to be a difficult part of our job as software engineers. Most of the times, it takes more time to deliver features than initially estimated. Why is this and what can we do about it?

The difficulties with estimating

Most things are new

The difficult part in writing software systems is, that most of the work we do is new to all of us in the team. That makes it sometimes difficult to give a realistic estimation. When you make an estimation, you will lean on previous experiences. It’s the same as traveling by car to a certain destination. When you know the distance of the trip (the complexity of the task) is a number of kilometers, you know you will need let’s say half an hour traveling to it. By estimating software, you will also use the knowledge of how much time a previous task took you to estimate the new work.

An estimation becomes more and more uncertain when you have to estimate work you aren’t that familiar with. Although you can have a rough guess, it would never be that close to the estimated work which is similar to work you did before.

Nature of the people

Due to the nature of software development, most of the people are introvert. This is a fact and we better make advantage of this information. In her book “Quiet: The Power of Introverts in a World that Can’t Stop Talking”, Susan Cain describes that introverts in the neighborhood of extrovert people often tent to make more optimistic promises than between other introverts. Managers or other people in the management are more likely to be extroverts, hence might lead to underestimation of tasks.

In his book “Thinking, fast and slow” Daniel Kahneman, suggest that people over-estimate user stories where they think they might not get the task. Since losing takes a huge emotional toll for people, people do not like to lose.

People mostly like to identify what they create with themselves. Take for example a plastic surgeon. He or she will be proud when a wound is recovered nicely due to a bicycle accident. If you address the surgeon personally when he messed up the surgery, he will feel personally addressed. This is also the fact with a software engineer. You see within estimation sessions when somebody discusses the estimation of someone with “Why does this take so much time? That can be much faster?”, the engineer feels his or herself personally attacked. He want not say no, since this will hurt his expertise.

How we can improve our estimations

Given the fact we given most of the times a to optimistic estimation, most of what we do is new and we have to deal with personal behavior, how can be give more realistic estimations?

Knowing what needs to be done

Seems like an open door, but most of the times within the team not having the same view what needs to be done leads to confusion. The definition of done helps to define when a task is ready to ship.

But also during the backlog refinements the Product Owner can help the team to understand a task, leading to better estimations. By backlog planning, you go through an item several times and gain insight over time. It helps the team better to understand what needs to be done and how it should be done. By discussing and thinking about it overtime it will grow in the developers minds.

Finally, when you don’t know how much it will take, admit don’t know. Plan a spike for this to plan for the next sprint how much effort it will take to complete the task.

Make smaller chunks

Writing the sub tasks that needs to be done in a so-called work breakdown can really help. It helps you break down a complex task into smaller comprehensible parts.

Create an environment where people feel safe

Create a learning friendly environment, where people are encouraged to make mistakes. In this way, people feel safe to learn from their mistakes, but also don’t tend to give to tight underestimations. Make the developers aware to take it not personal when their estimation is to be criticized.

Make estimations independent from your colleagues

Planning poker is a nice example of making estimations independent from colleagues. In this way, you don’t influence each other. In case of big differences, you can argue the decision of these different estimations leading people to other insides. Besides planning poker, there are a lot more of planning techniques that allow estimations independent from each other. Some examples which are mentioned within the book “The Clean Coder” from Robert C. Martin:

Reflect on the estimations

As Daniel Kahnemen suggests in his book “Thinking, fast and slow”, the time where you have feedback from what you did must be small for the brain. So have a look at your estimation when you’re finished a task. Agile has a reflection session at the end of each sprint. Use this reflection session to discuss tasks that really took more time than initially estimated. Try to learn from it.


The reason why estimations often fail is that we developers tent to underestimate. I gave some reasons why this happen and what we can do about it. The main message is: be aware of underestimation and take your time to understand what needs to be done. Also be aware of the human aspect: don’t take it personal and be aware of influences of other persons. This gives you a big advantage for a better estimation.

Posted in Agile, Best practices, Scrum by Bruno at April 1st, 2017.

Leave a Reply