We cannot predict the future. What we can do though is to make a forecast, an estimation, which would be an smart guess at worst and educated guess at best.
Some developers really suck at estimation. Most likely this is because they don’t care about estimation at all. If you’re one of them, please move along.
On the other hand, if you really care about how you estimate, then a question “How can I estimate better?” has probably passed your mind once or twice. The truth is, I don’t have a magic pill, but I do have 5 simple steps that might improve your estimation.
1. Stay engaged
When estimating in the distributed environment, that is, being in front of your computer, it is really easy to get distracted by all sorts of things. An email arrived here or a Skype message popped there, and off your brain goes — it switches to another task, transforming an important ongoing discussion into the background noise.
The advice is simple — switch off all the possible distraction sources. Nobody will suffer if you answer that message 40 minutes later.
Another typical mistake is committing to something without analysing it properly. A common situation is when a team estimates something you have no idea about. Not wanting to look awkward by asking inappropriate questions, you simply decide to agree with the proposed estimation.
Don’t do that.
Avoid committing to uncertain items under the peer pressure. Try to nail it down. Ask a question. Try to understand. Ask again and say honestly that you don’t get the task. There is nothing awkward in being honest. In most of the cases it simply means that the task description is not accurate.
3. Think relative
Now, look into the window now and try to spot 2 buildings that are close to each other. Can you tell right away, what is the height of each one of them or how many floors are there? I bet you can’t.
But can you tell how do those buildings relate to each other? I think you can. It is fairly easy to estimate how many times a building is higher than its neighbour. Now, if you project this approach into estimating, you’ll see that when estimating tasks our brain always tries to think in absolute terms, e.g. time. Even when we estimate in story points.
It’s entirely possible (and fairly common) for development teams to engage in what might be called indirect, absolute estimation. This occurs when point values are merely substituted for their absolute equivalents.
What actually happens is we are trying to predict how much time would a task take, and then we somehow try to convert this time into the story points. What we should do instead is to estimate tasks relatively to each other.
Let’s say you need to figure out the height of three buildings (5, 12 and 20 floors, but we don’t know it yet). So instead of smart guessing size of each building, you have to smart guess only the smallest. Then you just estimate based on the smallest estimation and on their relation. This way you estimate faster, more accurate and with less brain resource consumption.
Well, you’ve got the idea.
4. Be pessimistic
Don’t get me wrong, I don’t like dealing with pessimists. Not unless it comes to estimating.
If you want to estimate better, you have to put those “pink glasses” away. Whenever there is a smallest hint of uncertainty, think of the worst scenario, and estimate with it. Otherwise, you are risking to end up paying your own time for the scenarios that were out of your control.
I must admin, that your product owner might not like this attitude. But in the long run everyone will see the benefits of such approach. You might even train your
dragon product owner to create better, more granular descriptions in order to eliminate this “negative” attitude of yours from the planning poker sessions.
5. Stop when tired
It sounds obvious yet so many people ignore this simple rule. Do not estimate when you are getting tired. There is always this desire to finish of the planning backlog completely, even if it spans for longer hours. I know, I’ve been there. I especially remember the situations when the team has estimated 15 stories during 1 hour, but there are still 5 more to go.
This small amount pushes everyone to their limits. But as bad we want to finish planning poker meeting with the empty backlog, as bad becomes our estimation accuracy when we are tired. In the depths of our minds, we don’t want to be accurate, we just want to finish this thing and leave it in the clean state.
As result, we pay later with some unpredictable uncertainties. Oftentimes they could have been avoided, if we just gave them a proper thought. Just think about it next time you want to push it to the end.
I hope you start applying those steps now. Remember, it is not important to put all of them at once. You could pick either of the steps that you think can be achieved best given your specific environment, apply it and observe the improved results. This will motivate you to apply more of them.
Here are some useful posts if you seek more abstract advice:
- How to Make Accurate Time Estimates
- How to Get Better at Estimating Time for Tasks
- Learning to estimate development time accurately
Please let me know your opinion in the comments, or let me know if you have any other tips for fellow estimators.
Also, if you liked this post and if you wish to receive new posts straight into your inbox — please, sign up to my mailing list.