Think Twice Before You Plan Your Work as a Software Engineer

This is my first medium post so bear with me.

Lately, I’ve been toying with the idea of “overestimating” the tasks during our regular planning sessions. The motivation came from the book Essentialism by Greg McKeown that I have been picking up during the past couple of months. There have been other interesting ideas that relate to the field of Software Engineering but I will attempt to explain those in the future.

Role of estimations

The purpose of estimating every task that you will be tackling for the next X days is to make sure that the amount of work you’re taking on is reasonable and that the team will be able to complete it. In other words, it is right on the edge between impossible and not challenging enough. However, as anyone who has tried estimating some piece of work before they do it (especially in the field of Software Engineering), coming up with a time frame is rather difficult. In the majority of cases we humans tend to underestimate the job and overestimate ourselves.

Our Workflow

One way to plan your work as a team which we’re using currently is the Fibonacci sequence to estimate the effort that a certain task should take. That is already one protection mechanism against making unrealistic expectations. There is a big difference between a 3 and 5 in my eyes and I’m challenged to think more carefully about exactly what is needed in a certain task.

Why “overestimate”

Okay, so we have talked about why we plan our work and the role of estimations. How can Essentialism help us here? One concept that stood out to me is the idea of adding a buffer to your estimations. The idea is simple: every time you estimate a piece of work, add a buffer percentage to your estimation. Instead of basing your story point on that one sprint that went awesome and everyone killed it, consider focusing on your average performance week-to-week. Add a buffer of 25 to 50% to account for unexpected turns. It’s inevitable — things will take longer than expected, production systems will break and need additional support, unplanned meetings will pop up in your calendar. It’s better when everyone is prepared in such events and can reach the team goals despite these interruptions.

But Why

We have talked about why we plan, why we should have a buffer but one thing remains to be tackled: Why does this happen in the first place? Are we so short-sighted that we cannot account for unexpected events? Well, yes and no. It’s true that we often base our estimations on “outlier” situations where we have been able to smash our tight deadlines. However, there is another important reason — peer pressure. Let’s face it: when estimating our work, we are very easily swayed by the estimations of our teammates. This holds particularly true for juniors and graduates — when we are starting we want to avoid at all cost looking like a liability to the team. This will cause us to go along with the group and avoid “overestimating” which is a total no-no in our minds.

A similar example is given in the book — students routinely underestimate the amount of time their work will take and end up suffering later as a consequence. Something quite interesting is that, if the estimations are provided anonymously, this bias towards underestimating doesn’t manifest. Another point for the argument that peer pressure plays a role here.

So there we have it — we have talked about why we plan our work as software engineers, how we go about doing so, what are some chinks in the armour of this process and what we can do to combat that.

I hope this has been useful.