Using time as an estimate6 min read

In my time as a Product and Project Manager, I’ve been lucky to have worked with over 10 different teams. Some of them had been working together for many years; others had been just assembled to tackle an important project. Some of them were comprised of senior developers; others, juniors. As a result, I’ve learnt that there is a different type of estimation which is best suited for each team depending on the personality of the group, on their main objective and their way of working.

These types of estimation also have their own distinctive qualities and shortcomings. In the following articles I’ll detail what I think the pros and cons of these types of estimation are and when I think it’s best to apply one or the other.

  1. Time as an estimate (this article)
  2. Complexity as an estimate pt1: t-shirt sizes (coming soon)
  3. Complexity as an estimate pt2: story points (coming soon)
  4. Value as an estimate (coming soon)

Time as a determining factor of success

Using time as an estimate is quite common in small teams or in individuals. This is because, intuitively, most people associate productivity with getting the maximum number of tasks done in a certain period of time.

While highly debatable (I, in particular, don’t agree with this definition of productivity), this is the most common understanding of what productivity is and, hence, will result in success being measured by how many tasks are done in a certain timeframe, e.g. 10 tasks per sprint.

Popular definition of productivity = tasks done / time spent

Therefore, since we want to be able to predict how productive we or our team will be, we need to be able to measure these two factors: number of tasks and time spent. While the former is always known, measuring and predicting the latter is highly complicated, resulting in inaccurate estimations and, as a result, in very inaccurate plannings.

Uncertainty leads to inaccuracy

It’s no secret that estimating how long something will take is highly inaccurate. One of the main reasons for this is that we humans are very bad at estimating how long something will take. This is especially true when the task to be estimated is new, unclear or unknown.

Estimations rarely consider problems popping up

While there are many different theories as to why this is the case, the most accepted one is that we focus on the ideal scenario, e.g. I will sit down, start working on this task, not get distracted and finish it in one go. Reality, though, crashes these expectations by making us unfocussed, shoving urgent problems onto our desk, or uncovering many problems with the task itself that make you stop, ask for help, or block you altogether.

No rules required to start estimating

While other estimation techniques require learning certain rules and following them, using time as an estimate is immediately understood by anyone, and anyone can do it from the beginning.

However, this strength is also its biggest weakness because, since anyone can estimate using time, it can be used by anyone to estimate the wrong tasks or without having the complete picture in mind. This right here is one of the main reasons why time estimates fail.

Repetitive work is reproducible work

Nevertheless, it is also true that we humans are relatively good at estimating how long something will take if we have performed that task several times in the past and it is easily reproducible.

As an example, if someone asked you how long it would take you to do the laundry, you would have no problem in replying, since gathering the clothes, separating them, putting them in the washing machine, hanging them and finally folding and storing them are tasks that you have already done many times, they are predictable and you already know how long doing them takes.

The problem comes when we extrapolate this to tasks that aren’t easily reproducible, e.g. developing and implementing a new functionality to a website or moving houses.

Moving houses can be traumatic, especially if not planned properly

Because of these tasks being more complex, unclear and not really reproducible due to their nature, you will probably forget about certain factors to take into account. In our moving houses example, these problems can be not having enough boxes for everything you own, not finding a van as large as you would have liked (resulting in more trips to make), or less friends than initially expected helping you in the end.

“How long will this take?”

Stakeholders usually want everything done yesterday. This is something that’s intrinsic to them, resulting in constant impatience from their side to see the completion of a project or functionality.

Stakeholders are quite the impatient bunch

Consequently, “How long will this take?” becomes their frequently asked question and, as a PM, you need to be ready to have an answer ready or you’ll give the impression that you’re not aware of the status of your projects.

The trap that we fall into is that we tend to try to answer this question by estimating how long each task will take and then summing all these estimates up, resulting in an overall time to completion. While this might help you answer to your stakeholders in the short term, it probably will come back to haunt you in the long term if the initial estimation isn’t met.

Pros and Cons of using time as an estimate

Pros of using time as an estimate

  • Intuitively out-of-the-box, requiring no or very little learning/teaching.
  • Gives you an idea of how long a project will take at a glance.

Cons of using time as an estimate

  • Highly inaccurate when the task is new, unclear or not reproducible.
  • Being easy to use can easily lead to wrong estimations.

When you should use time as an estimate

After considering all of the above, I believe that using time estimates should not be used in software development.

The reason is that, as we’ve seen, time estimates are only useful when the task is clear, easily reproducible and has been done in the past, and this is rarely the c ase when it comes to implementing new features or fixing bugs.

Therefore, I highly advise using complexity as an estimate instead, as I’ll elaborate on in future articles.

Leave a comment