This is a guest post authored by Krista Miller of Programming in Pink.

Krista is a .NET web developer who empowers, encourages and educates women fighting their way through the tech field.

Time estimation is one of those tricky job duties that programmers tend to struggle with and until a couple of months ago I was completely awful at it myself. There are many reasons that people don’t like to estimate time needed for a project.

However, we can’t always avoid giving estimates.  If your boss comes to you asking when you expect to be done with a project you can’t say, “Oh I don’t believe in time estimation, it will be ready when it’s ready” even if that would be nice.

I’ll start by explaining some of the reasons why people don’t like to estimate.

Why Don’t People Like Time Estimation?

Here are a few reasons people don’t like to give time estimates:

• Hofstadter’s Law – “It always takes longer than you expect, even when you take into account Hofstadter’s Law” – Douglas Hofstadter
• Parkinson’s Law – States that work will expand to fill the time available for it. Have an hour to complete a task? It will take you an hour. Suddenly only have 10 minutes for that same task? You’ll get it done in 10 minutes!
• The Cone of Uncertainty – Explains that early in a project our estimations must come in the form of a range, due to unknowns. As we go through the stages of collecting requirements, completing requirements, designing the UI, and working through the code there are fewer unknowns, making our estimations more accurate. However, this means that we can’t give a perfect estimate until we are done with the project. There is a great post by Agile In a Nutshell on how to better handle the Cone of Uncertainty.
• Programmers are constantly dealing with changing requirements.  Unless you are in a position where you can always say “no” to changes, odds are you’ll have some extra requirements (and time) added to each project.
• It’s easy to underestimate the complexity of a project, therefore underestimating the time needed to complete it.
• It is also easy to overestimate a project’s complexity, leading to an overestimation of the time needed to complete it.

With that being said, most of us can’t avoid giving time estimates occasionally.

How I Improved My Estimation Accuracy

I’ve been using the Pomodoro Technique for several months and completely love it.

After using Trello and a timer app to track my Pomodori for several weeks, I heard about KanbanFlow. Unlike Trello, KanbanFlow has a built-in timer and a section to break each task down into subtasks.

You are able to choose your current task at any time and as your timer counts down, time is added to the chosen task. When you’re finished with the project, you have the total time right there in front of you.

So how does that help?

Breaking Tasks Into Smaller Pieces

Breaking up your tasks almost immediately makes your estimations more accurate. It helps you to think about any actions you may have missed and it is easier to estimate the time needed for smaller tasks.

In the below example, I included a breakdown of my steps for writing this blog post. I am able
to get much closer on time estimations for tasks such as “Brainstorm” or “Outline” than tasks like “Write blog post”.The same goes for parts of a coding project.

When I started breaking down my tasks I realized that I often left out time for initial investigation, research, code reviews, refactoring, testing, and checking-in files.  Basically my time only accounted for the actual coding and maybe a little extra. I am now more accurate and have a much happier boss!

Research

I hinted at it above, but breaking your main project into smaller tasks will encourage you to do a little
research before diving in. Doing some initial research will help you identify any parts you may have missed, existing code that could cause trouble, and additional information you will need to gather.

Or it could work in the opposite direction and you may find that parts are already done for you!

For example, just a couple of weeks ago I had a task assigned to me that was estimated at 25 days. I
got started and found that the code had been written 2 years ago by the person I replaced and no one knew about it. Quite a nice surprise, if you ask me!

Either way, spending a little time on initial research will help identify some of those little things
that tend to pop up in the middle of projects.

Track Your Time

Many programmers don’t actually track their time. They say they need a certain number of days for a project and maybe at the end they know about how many days they worked on it. But do they know how much actual time was spent on that activity? What about checking email, maintaining other projects, or new projects that sneak in?

Tracking time for each individual project will help you see exactly how much time was
spent on it.

KanbanFlow makes it easy to enter an estimated time and then keep tabs on where you actually are throughout the project. Below you can see that I estimated this post would take me 4 hours and 30 minutes to complete and so far I’ve spent 2 hours and 6 minutes on it.

Remember Hofstadter’s Law and Parkinson’s Law? I bet if you follow the above steps and track your
time that you’ll hit the mark every time!

Reflect

When the task is completed you can then take some time to reflect.

If your estimation was off can you determine why? Did you forget to include a subtask? Did something turn out to be more difficult than anticipated? Did another project come up and take your time away from this one?

Keep those things in mind and take them into account when estimating your next project.

Or, if your estimate was accurate, pat yourself on the back, note anything you did better this time than
last time, and thank Hofstadter and Parkinson.

What Do You Think?

What are you thoughts on time estimation? Do you think it’s important or is it something we should try to avoid?

Do you have any tips that I missed? Comment below, I’d love to hear from you!