Practising XP

Time-based estimation is frequently used in software development projects, even though it is far from being accurate or efficient. Here’s a deep dive into the inherent problems that should prompt both developers and managers to avoid this approach.

Always Wrong

A contextual exploration of time-based estimates builds a strong case against this estimation approach.

Too much guesswork

Project estimation often begins with the question: “How long will it take to complete this task?” This is, essentially, a compound question that sits on top of others, viz., how big is the task, how long will each team member take to complete their part, what’s the environment like, etc. Each of these “sub-questions” is tough to answer, leaving enough room for speculation. You’re making guesses about your ability, the environment, or the dependencies you may encounter. Cracking the bigger question amounts to summing up this speculation. No surprise then that estimates derived thus are inaccurate.

Too many options to choose from

An open-ended and broad spectrum of period is available for you to choose from when using time-based estimates. You could say the task will take 4 hours, 1 day or 8 days or 10 days… The wider the range to choose from, the higher the probability of getting it wrong. The estimates could go wrong because there is a strong likelihood of under-estimating or over-estimating the numbers. Either way, the detrimental impact on future roadmaps is imminent.

Guessing on others’ behalf

Let’s assume that you can answer questions about your own ability correctly. But can you do the same about your entire team, especially if it has members not known to you? You’re guessing again, and this time it’s about another person. Estimation based on such assumptions can be dangerously off.

Harmful pressure and negative reactions

Considering the above reasons, the numbers will never be accurate, even if you think they will. This dissonance creates pressure. Further, time-based estimates are very precise and this preciseness could work against you. You may be confronted by managers or clients who hold that number sacrosanct, or you could come down hard on yourself because you do know that looming precise number is impossible to achieve. This pressure—whether self-inflicted or imposed by others—puts you on the back foot and finger-pointing becomes rampant in the struggle for self-preservation.

During estimation

You react to this pressure by being extra cautious the next time you plan. You could take longer than needed to estimate or then seek too many details too early or make up what’s not available or even get immersed too soon in the intricacies of a solution. You’d like to believe this extra vigilance is required for accurate estimation. However, at this point, this is nothing but wasteful effort.

Another reaction is to play it safe by padding up the estimates. It’s impossible to ascertain the exact time required and so buffers seem like a good option—at multiple levels. The developer, project manager, delivery manager, or even the client stakeholder each adds a buffer at their level. Such padding upon padding is risky because what each one is really doing is making up a number and then cushioning it further.

During execution

Just as with planning, the execution phase encounters its unique share of problems. Once development starts, you could find that the size of the task is different from what was assumed during planning, or the speed of work is getting affected by extraneous conditions. This race against time during execution turns up the tension again, leading to two types of typical behaviors.

Quality suffers

You either cut corners during development, thinking that it won’t make a difference or that it will go unnoticed. You may even try to bridge the time gap by working longer hours. If such overworking becomes habitual, it jeopardizes creativity, spirit of innovation, clarity of thought and, of course, quality.

Work expands to fill time

Alternatively, you may come face to face with over-estimation. The incentives for acknowledging early completion and taking up a new task are low. You do not want to call attention to your over-estimation or raise suspicion about buffers and bloated estimates. So, the extra time gets spent in gold plating or expanding to previously committed timelines or even slackening the pace of work. Knowing there’s time to spare makes it okay to take it easy and invest no extra effort in pursuing and closing dependencies.

Collaboration suffers

It’s not only the project processes that get affected by this erroneous approach; the team suffers too. Developers working on individual stories find themselves caught in a web of self-doubt or unhealthy comparison and competition as the clock ticks away. Derogatory self-talk like “I’m just slow at my work” or accusatory statements like “You’ve been late in the past too” or “Let me show them who’s faster” dominate interaction instead of collaborative conversations.

With team members pitted against each other, the casualty is always software excellence. Rather than concentrating on writing and getting out the best piece of software, developers find themselves cutting corners, adding buffers, working overtime or trying to out-do team-mates—a host of negative behaviors that originates in the pressure created by faulty time estimates.

Tracking progress is tough

We’ve established that time-based estimates do no good for developers. Do they then work well for project managers or stakeholders who are interested in tracking the team’s progress? Not at all! That’s because tracking how the team is doing against these estimates is also tough to get right.

Firstly, conversion of estimated days into real days is tricky. No developer spends all working hours writing code. Sundry activities like meetings and discussions eat into the day and tracking such digressions is complex.

The other difficulty is the sporadic nature of daily work. Work can get parked because of a dependency or a change in requirement or the unavailability of a team member. At the end of the week, reporting accurately on the hard effort put in by each developer on each story is a real challenge.

Blame game instead of course correction

The challenges notwithstanding, maybe the most diligent of managers are able to sort out the tracking conundrum. The tracking sheet is prepared in granular and accurate detail and what it’s telling you is that the project is lagging. You land up in a stressful situation again, and as happens, the stress disregards all reasoning. You end up drawing irrational conclusions—about yourself and others.

Blaming yourself: Because you can’t disconnect from the numbers you came up with at the outset, you tell yourself they are right. “The fault has to be in my execution.” It’s easier to blame yourself. “I am not working as hard as I should.” And you can even be convinced that you are not good enough. “I don’t have the right skills for this job.”

Blaming someone else: Despite your best efforts, you cannot foresee what can go wrong in the project. When things spiral out of control, pinning the blame elsewhere becomes the coping mechanism. “The team wasn’t right” or “Something went wrong in the process” or “They did their bit 2 days late and I’m now 5 days late.” The fault always lies elsewhere.   

At this point in the project, owning up that you started off with the wrong estimates feels overwhelming. It seems less risky to say something went wrong during execution or to even blame yourself. Sadly, this gets you nowhere. The project has already suffered, and development quality has paid the price.

It’s imperative to accept that time-based estimates are of no use to anybody on the team. Kicking off the project with this approach is starting off on the wrong foot. It’s time for teams to abort this practice and consider viable alternatives like story points. Stay tuned for more on that!