What is the best way to estimate tasks in Agile Methods?

Nowadays in Software Project Management, we have different ways of estimating how long a task can be completed, namely by time or by complexity. Previously, in the waterfall lifecycle model, each process is allocated a time and is followed sequentially.

So what is the most effective way in Agile Methods such as Scrum or Lean?

Analysis all of the possible processes is way beyond this article's scope. I will nevertheless share my experience on the subject.

Time Estimation

Estimating a task by time is relevant if the person already knows the path to take especially if the work is of a repetitive nature. For example, in an ERP project, a consultant has to modify the default VAT for all products. This can easily be estimated at around half a day of work including a test plan and a brief documentation.

The Problem

But how about fixing a bug with a payment solution that has been integrated in the application whereby at first sight, the problem lies with the provider. Only adding a time estimate is not enough - even if you break down the task into sub tasks.

A better solution is estimating by complexity. Time estimates unnecessary adds pressure to the programmer putting more emphasis on quantity rather than quality. We sometimes have to cut corners just to deliver the work in time.

In addition, people estimating the tasks are most probably not the ones who are going to work on them and/or technically don't have enough exposure on the project(s). On the contrary, they can also have too much experience and as experts in the field, they tend to underestimate the work to be done by others, particularly novices.

Since for them the tasks are easy, they think it's the same for others as well - particularly junior developers in our case.

The reality however is different. Trivial things such as project configuration can take a toll on beginners which reduces our overall productivity until we are comfortable with the subject.

Billing clients by time?

The idea of estimating tasks by time comes due to the fact that this is the way development organisations traditionally charge their clients. However, this does not reflect how the world operates daily. Just imagine, paying a plumber per hour instead of work done. Or a taxi driver charging you per time instead of destination.

In addition, when we are working in such tight time constraint, we are often interrupted by colleagues concerning other tasks. Now do we ignore them and continue our work in hope that we manage to finish in time, or do we take the risk to help them and fall behind schedule?

At the end of the day, the question arises: which is the best solution for the entire organisation? Learning from the best enterprises out there can point us the solution, especially from Toyota Production System.

In real life, most tasks are not estimated by time, rather by work done which is then broken down by complexity.

This is how most Agile methods recommend doing.