Effort estimation —  it’s complicated
Tags: softwaredevelopment, softwareengineering, timemanagement, noestimates
Published: 2020-05-12 08:48:38

---
title: Effort estimation —  it’s complicated
published: true
date: 2020-05-12 08:08:59 UTC
tags: software-development,software-engineering,time-management,noestimates
canonical_url: https://medium.com/@dvirsegal/effort-estimation-its-complicated-8e1c77bf572c
---

![](https://cdn-images-1.medium.com/max/1024/0*TZhxsd2wzYBOei5Y)<figcaption>It’s complicated — Photo by <a href="https://unsplash.com/@dnevozhai?utm_source=medium&amp;utm_medium=referral">Denys Nevozhai</a> on <a href="https://unsplash.com?utm_source=medium&amp;utm_medium=referral">Unsplash</a></figcaption>

### Effort estimation — it’s complicated

#### On the dilemma of evaluating software development effort

For the past few months, estimating effort, a long-standing dilemma of the software industry, bothers me. How should we, as SW engineers, deal with the accuracy of effort estimations? The answer is complicated and has implications over developers’ career growth, having an impact on personal development. There is much at stake.

{% tweet 1220749391172120577 %}

So, I felt the urge to take action. I decided to share my doubts about it over twitter.

{% tweet 1236979823098109953 %}

Which led to an interesting (IMHO) debate over this subject. Below I’ll try to outline the various arguments.

#### No Silver Bullet, Estimation is hard.

First, I’ll start with [Michael Shpilt](https://twitter.com/MichaelShpilt)’s reply, saying that effort estimation is probably one of the hardest things in software, he’s right. Suggesting that to reduce the risk of failing to estimate accurately, one should be knowledgeable about the application’s domain.

Besides, the estimator should choose ahead of time who are the developers that going to participate in the required feature development. Stating that choosing the best-fitted team-members based on their codebase familiarity will help in reducing the risk.

I tend to agree on the necessity of specific knowledge in the application’s domain, as without it, things might go the wrong way; it is crucial to the success of the development.

As for choosing specific people, it is a task that should be done gently, estimations shouldn’t be based on particular people’s involvement. It may result in a lack of motivation among the team because only specified individuals get specific assignments. Feelings should be considered too, we are not machines. If you insist on proceeding with this procedure, make sure to communicate why to soften the message.

Furthermore, as broader the unknown, the higher chance a senior developer will be able to mitigate the risk. Leading to the point that inexperienced engineers won’t be able to gain knowledge about unfamiliar parts of the system. I guess the truth is somewhere in between.

[Tal Joffe](https://twitter.com/TalJoffe) mentioned the excellent [talk] (https://summit2019.reversim.com/session/5c7859231503d900172c583e.html)(in Hebrew) given by [Itay Maman](https://twitter.com/pembleton) on [Reversim 2019 summit](https://summit2019.reversim.com/). Itay has made his [slides](https://docs.google.com/presentation/d/1oW6l71Pl8eFS4v_iQQ_-Y2Zf3NqBdhxQyd4g9NmP0Y4/edit) available (🙏), which may assist for non-Hebrew speakers.

{% youtube UMZnZBJ28ew %}

In his talk, various points are being raised, helping to lower a few of the risks mentioned above. Tal’s takeaways summarized it well. He says that the lecture’s main delivered message is the need to focus on high-level estimation.

Meaning tasks should be broken into buckets of effort — a few hours/one day/few days/more. The “More” is Tal’s version for tasks that take longer than a few days, forcing him to break them down to smaller tasks and repeat the process.

I tend to agree with him. Smaller tasks allow accurate estimates and create opportunities to share the development effort between team members, including the inexperienced engineers (and as a by-product gain knowledge and mentor them).

However, Itay has pointed out that it will only shift the estimation’s difficulty to the challenge of identifying the smaller chunks, making it work only in theory. There is no _panacea_ here - It’s harder than you think (IHTYT).

#### Is #NoEstimates the answer?

![](https://cdn-images-1.medium.com/max/1024/0*PWscJKhELnIKMR1X.png)<figcaption>NoEstimates as summarized by <a href="https://medium.com/u/a2f578ccd73">Magnus Dahlgren</a> — <a href="https://magnusd.cc/noestimates-just-story-points-done-right.html">source</a></figcaption>

As stated by [Gal Zellermayer](https://twitter.com/GalZellermayer), you should start with the why? It will help you understand the need, forcing you to adjust your estimation methodology accordingly.

> Some are very thoughtful, others are guesstimates. Some are detailed oriented, others are high level. Maybe it is just for self-improvement, or maybe you don’t need it.

This approach is especially true when there is no baseline to compare with.

Another essential fact raised by [Ophir Harran](https://medium.com/u/42fc817eddb) as a reply to Gal’s tweet. In his words, accepting failed estimation is vital over time to improve accuracy; otherwise, you buffer 3x to mitigate, and that cripples teams.

Couldn’t agree more on that, it may lead to the false perception that effort estimation == duration, which is the root of all evils 👹.

It creates the impression that teams should finish their development tasks based on a given number. Without considering it was an estimate (which might be inaccurate depending on the number of unknown factors). Moreover, it _might_ start a blame game (Also mentioned by Itay) between team members on who should take responsibility for the delay\failure to deliver. Resulting in, paying the price of quality hit and surging technical debt, leading to customer dissatisfaction.

[Omer Raviv](https://twitter.com/omerraviv) joined both of them in recommending [Woody Zuill](https://twitter.com/WoodyZuill)’s approach, #NoEstimates. If you haven’t watched his talk, go ahead and watch it. It’s a must.

{% vimeo 159496089 %}

Omer said that it may sound dramatic at first. Still, it might be just a call to explore other ways to solve things without asking how long will it take while avoiding spending time overestimations.

In his talk, Woody suggests to select the most essential feature, break it down into a smaller neutral piece of work, develop. Iterate till you ship it or until it is no longer critical.

![](https://cdn-images-1.medium.com/max/1024/0*d32gmyWKzH8BmL-v)<figcaption>NoEstimates in a nutshell — Source: <a href="https://vimeo.com/159496089">https://vimeo.com/159496089</a></figcaption>

He even replied to my tweet. Explaining that in his talk, he shares how he works without estimates. But does not insist that it is the only way to work without estimates, or as [Martin Fowler](https://martinfowler.com/) said in his [blog](https://martinfowler.com/bliki/PurposeOfEstimation.html):

> If they are going to affect significant decisions, then go ahead and make the best estimates you can.

#### Overall

My main takeaway is that as SW engineers, we should always question the practices we use, be open-minded about it. If we’ll say “_It’s always been done that way”,_ we won’t progress. Having doubts over our work procedures will push us forward, making us a bit better every time.

This reminds me that software is made by humans, so consider it when you take any action.

AHA and, don’t assume! define metrics, measure, and then forecast.

![](https://cdn-images-1.medium.com/max/640/1*xWal5O4ohzvPlapVxU-USw.gif)<figcaption>Assumptions — <a href="https://gfycat.com/ambitiousaccomplishedantarcticgiantpetrel">Source</a></figcaption>