DEV Community

Cover image for Let's talk about estimation.

Let's talk about estimation.

Elizabeth Alcalá on April 21, 2020

I struggle a lot with estimations in my two years as a developer. And I'm not the only one, most of my coworkers struggle with this too. ...
Collapse
 
dvddpl profile image
Davide de Paolis

very nice article.
i'd really like to stress out the communication part. Be clear an be honest, stop saying you arealmost done - or I hope to be done.
And no. you are not going to loose credibility if you ask for more time and a deadline extension. everybody makes mistakes, or realized there were flaws in the design, holes in the requirements or that the estimate was not accurate ( btw. it should be made - discussed by at least 3 people).
You loose credibility when you say until the very last day, all good, i will make it - and then you don;t your code is a mess and full of bugs.- and not even the first time you do that, but only if it becomes an habit of yours..

Collapse
 
elisealcala profile image
Elizabeth Alcalá

This. You need to be clear about what's going on. When your manager asks you how are you going, don't just say, good, fine, I'll make it. It's better to be more precise about what tasks are already done and what is left. If you are clear about your progress every day, it will definitely be better than just wait until the last day to say everything you didn't do.

Collapse
 
panoscodes profile image
Panos Dalitsouris

Well said 👍

Collapse
 
jwp profile image
John Peters • Edited

Thanks Elizabeth, in my 30 years in the industry, I've seen project estimates on due dates fail around 95% of the time. Don't know if that's any consolation, but I believe that estimating time-lines is impossible. I think that's why Agile introduced the idea of Fibonacci sequences; however, even that tends to trend toward direct Time-lines. The only hope, in my mind, is Continuous Delivery, and the 'we'll deliver it ASAP' along with other deliverables which are working. It's just a better way to go.

Collapse
 
elisealcala profile image
Elizabeth Alcalá

Yes, but in that way, your client/manager doesn't know an estimated time, and I don't know, it could work if you maintain constant communication because in the other way it will end with just questions of what when this will be ready and so on.

Collapse
 
jwp profile image
John Peters

Yes daily stand-ups tend to solve the communication problem with the exception that often, regardless of impediments; the due date never changes. When that happens then it's probably best to look for another job..

Collapse
 
hiclab profile image
hiclab

Humans are in general not good at doing estimations especially when the uncertainty is always present. This is why we should not promise what we cannot deliver on time.

Developers usually tend to inflate estimates for fear the work will take longer than excepted, what in my opinion cannot be a solution to this problem. As the hofstadter law says: "It always takes longer than you expect, even when you take into account Hofstadter's Law".

Developers should focus on delivering value rather than trying to meet unrealistic deadlines.

Collapse
 
elisealcala profile image
Elizabeth Alcalá

In some cases, there are developers who underestimate projects. Sometimes they want to prove that they can do it in less time. I think the answer is to focus on the value and to be clear and transparent about your progress.

Collapse
 
briand91 profile image
Brian Duggan

I think the key to stress-free estimation is, as a team, committing to a lower number of points/issues/stories/whatever per sprint/iteration/week. Less points committed to at the onset means more wiggle room in the event that the code you "estimated" at 2 is actually 5. And thus, I'd argue that it allows your estimations to actually BE estimations.

The fact that we even have the phrase "accurate estimation" and "precise estimation" and so on should tell us that we're fundamentally over-thinking it. As a mental exercise, try this:

Look at a random object somewhere in the room you're in now, and quickly estimate how far the object is from you. Just go with the first reasonable number that comes to mind without thinking too much about it.

I think if an "estimation" goes into any more depth than that then it's not estimating, it's grooming.

Collapse
 
crimsonmed profile image
Médéric Burlet

I agree with splitting the process. Also make sure to hard define features all it can do and everything else is considered outside of scope.

Another point is buffer, buffer, buffer, you will always run into a design issue or a bug or something along those lines which wasn't planned so do add a 20-30% buffer to the overall estimated time.

Collapse
 
elisealcala profile image
Elizabeth Alcalá

Yes, definitely. As you said, most of the time you'll run into bugs, it will help a lot if you have extra time to check that everything is working,

Collapse
 
jonrandy profile image
Jon Randy 🎖️

From 25 years of professional development, I can safely say that estimation is a waste of time. Seriously, don't do it

Collapse
 
andrzejwp profile image
andrzejwp • Edited

If only life was that easy ;)
There are 2 resources I consider valuable in terms of software estimation:

  1. Joel Spolsky's article: joelonsoftware.com/2007/10/26/evid...
  2. Steve McConnell's book: amazon.com/Software-Estimation-Dem...

I cannot recommend them enough - both for devs, as well as tech PMs.

Collapse
 
jonrandy profile image
Jon Randy 🎖️ • Edited

It really is that easy. I wasn't joking

You'll get things done faster, and write better code

Collapse
 
jonrandy profile image
Jon Randy 🎖️

A good quote on the subject:

Estimation is ultimately a futile effort. Software, more or less, is like writing poetry. Or solving mathematical proofs. It takes as long as it takes, and it’s done when it’s done. Perfect, or imperfect, estimation won’t change how long it takes to complete the work. If that sounds horrible to you, then go do something else.

Taken from here