How to Make Better Time Estimations?

Posted on Posted in Management

If you’re doing software development professionally, you’d be familiar with this problem:

  1. You receive requirements for a project.
  2. You come up with time estimate and/or a calendar date.
  3. You receive a go-ahead and start work on the project.
  4. Somewhere in the middle of development, you realize time is moving way faster than project development.
  5. You raise the flag and alert client. If client gives you more time, go back to #4. Otherwise go to #6.
  6. Client is annoyed and your credibility is under question. You spend days and nights and deliver a half-baked project.


Scenarios like above are so common (happens for almost every other project) and so important (threatens your credibility as a professional developer), yet the problem at the center is rarely paid any attention to.

Root Cause of Bad Estimations

Software developers tend to over-estimate their problem solving capabilities and under-estimate complexities in the project. When we learn requirements of a new project, we come up with bad estimations because we overlook a lot of complexities. We overlook those complexities because they’re hidden deep in the project details. And for any non-trivial project, it’s damn hard to be mentally aware of all of those nitty gritty implementation details, all in your head.

A Solution

One of my colleagues once shared a solution with me, which turned out to be one of the most powerful tools I ever learned. It has helped me over and over, and I’d like to share it with you. Here is how it goes:

STEP 1: Choose a Threshold Value

The solution begins with setting up a threshold time value, which can be set any number of hours. A usual number is 4 hours. I’ll share later how to select threshold time value.

STEP 2: Breakdown the Tasks

List down your tasks and assign them estimated number of hours. If any of your tasks takes greater than the threshold time value, break it down to subtasks. Now repeat the process for subtasks.

By the end of this exercise, your bigger tasks will be divided into several smaller subtasks, each of which will be estimated less than or equal to the threshold time value.

STEP 3: Get Duration in Hours

Now sum up estimated hours against each of the tasks, this should give you number of hours required by one person to complete the project.

STEP 4: Get Duration in Weeks

In an average working day, you don’t get to spend all of the 8 hours in focused work. A lot of that time is spent in other things like meetings, lunch, coffee breaks etc. So that time has to be taken into account for your estimations.

You have to be aware of total productive hours you get in a day. Let’s say it’s 6 hours (which is a lot). If you’re working 5 days a week, that’d make 30 hours of productivity a week. Divide your project hours with 30, and it’ll give you number of weeks to finish the project.

STEP 5: Add More People in the Team

Adding more people in the team does bring you more power, but it also comes with the cost of communication overheads. When you’re working alone, you know everything in your head and you’re soaring through the problems. But when you’re working with a team, you’ve to take care of meetings, emails, instant messaging and documentation so there are not communication gaps in the team. The bigger the team, the larger are the communication overheads.

So if you get 6 productive hours a day, and you’re working in a team of two, you might be left with 5 productive hours (with one hour going into communication overhead). That means you’ve a total of 10 productive hours a day, which is 50 productive hours a week. Dividing your total project hours with 50 will give you number of weeks required to complete project with a team of two.

Conclusion

This solution works because it brings hidden complexities to the surface. The magic happens in step#2 above: breaking down your larger tasks into smaller problems forces you to think over the details that you’d otherwise just overlook. The granular you want to think through details, the smaller your threshold time value should be.

This might not be a perfect solution, but it’s way better than making blind estimates: it helps you make more informed estimates and commitments. Try it once and you’ll never look back.

I’d love to hear your thoughts about it. Please share in the comments section below.

Leave a Reply

Your email address will not be published. Required fields are marked *