The Science of Software Estimation

Estimating software development effort is tricky and can often be a point of contention in the team. I have seen teams spending an entire day planning a 2 week sprint, working out every detail of every task. After a few sprints they have some sense of their team’s “velocity” and could predictability tell how much work their team can deliver in a sprint. And I have seen teams where developers huddle casually, take on major features, gives out rough dates, and miss their deadline by a lot.

I can’t propose a generic process for estimation as it’s highly dependent on the nature of business, team size, culture etc. And frankly I don’t even know what the best process looks like. Instead I am going to share some common pitfalls and best practices that are applicable for any development team. This is a useful read for developers and product owners alike.

It’s not just about code

Here’s how developers typically think when asked to give a quick estimate of a proposed change:

• Pull up a mental picture of the codebase (models, their relationships etc.)
• Gauge which parts of the codebase needs to change
• Add up the time required to make the changes and blurt it out

This is a flawed as it only take into account time required for programming. What about efforts required in testing, deployment, documentation, monitoring? Time spent on these often outweigh the programming time even for moderate size features. I recommend thinking through following things before estimating:

• How easy/hard it is to test this change
• Do we need efforts in documenting and communicating the change
• Does it require any infra effort like data migration, spinning up new app/db, setting up monitoring/alerts
• Would it require iterations to achieve the intended business outcome? E.g. just having a search feature in your app is not enough, we need at least a few iterations to get it right for most queries

Estimating unknowns = playing roulette

There’s natural tendency to overestimate work in unfamiliar territory and underestimate the effort when we know what needs to be done. While it’s natural, it’s not optimum. The way it fails in unknown domain is that the whole estimation function becomes degree of unfamiliarity multiplied by amount of perceived work. Isn’t there a better way to tackle this?

The ideal answer would be, “I don’t know at the moment, but I can spend few hours on it to get you a reasonable estimate”. Quick research on the problem can give you a pretty good idea about the landscape. Like what APIs/library/tools are available and how they might or might not fit your problem. You don’t need to know every last detail at this time but enough to commit on an approach and estimate the work based off of that.

Later, you might run into unknown unknowns and might need to alter the solution. But it will still be a much better estimate than just basing things off of unfamiliarity. The research time you spend is not wasted either as you have to do some version of it when you start working on the task.

A win-win exists more often than not

I have seen negotiations between developers and product owners that are completely centered around time. If the conversation goes just a level deeper and they discuss why would it take so long, there are ton of benefits. Often you realize that some nice to have use case is taking 80% of the time and can be decoupled from the core feature. That’s a win-win.

There’s also an intangible benefit of this for product owners. When you listen to why it’s going to take time, you build developer empathy. When you offer clever solutions to the problems, you garner respect in their (geek) world. This results in more engagement from developers and willingness to go out of their way to build the right things for you & the product.

Break down, decouple but don’t overdo

Let’s say you want to build some sort of live feed into your app. Now you need a way to push content from server to client (websocket etc.) and a quick access store for this feed (maybe a Redis cache). Now you ought to decouple these 2 bodies of work, be able to think about them independently and estimate the effort independently.

If you don’t decouple enough it becomes a hodgepodge, a breeding ground for muddled thinking. There needs to be clarity on how you are going to attack the problem. What x, y, z pieces are needed and how they are going to play together nicely. Without that kind of clarity we are just shooting in the dark. And it’s okay to be wrong about your solution but you at least need a working theory to be able to arrive at a sane estimate.

Now don’t go to the other extreme and waste time breaking down things at the lowest level of granularity possible. That’s a significant amount of time spent for marginal improvement in estimation accuracy. Rule of thumb is if looking at one line description of the task most of your team understands what needs to built and how then it’s okay to estimate at that level of granularity.

Given the noisy nature, some people usually question the benefit of estimation itself. I think as a business/product owner it’s super important to know how much time it’s going to take my team to build X,Y,Z into the product. It’s a key input to devise a strategy.

That’s all the advice I had. Next time you are estimating, pause, and think of a few of these techniques. Share your thoughts in the comments section and follow my blog if you enjoyed reading this.

View all posts by Amit Rathi

Originally published at blog.amirathi.com on February 5, 2018.

The Science of Software Estimation was originally published in Hacker Noon on Medium, where people are continuing the conversation by highlighting and responding to this story.