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.
But why it is so difficult?
I think it's because nobody teaches you how to estimate when you become a developer. You just learn it along the way, coding more and more until you can give a more accurate estimation of how long it will take you to complete a task.
Take your time.
When you are assigned to a project or task, take your time to know exactly what is required. Maybe it's a long project that can take months, or maybe it's a task that only takes a couple of hours.
Whatever the case, you can have an estimation in minutes or it could take you days. Make all the questions you have about the project, make sure the workflow is completed, if you have a design, ask the product team how this will look like in every possible scenario.
What if the requirements are not fully defined?
These are probably the most difficult projects to estimate. If you receive a text from a client who says he wants an e-commerce app but he's not sure about what payment gateway he needs, or the product team delivers a web design for desktop but not for tablet and mobile (this drives me nuts), you probably feel stuck.
It's important to point out that you can't give a precise estimation because you need more information, and that the time you define can be extended due to lack of information.
Split the process.
When you start working, always keep in mind the scope of the project; with that in your head, try to split the process into little tasks and go forward one by one. This will help you to maintain order and to be aware of what have you done and what is left to do. Many apps like Trello and Jira can help you with that. You can estimate this little task also, and that will help.
It's easy to get distracted.
The longer the project takes, the more difficult it is. I remember that I started coding a new feature, and I go back to an older component I made and thought Uhm, I think this needs a refactor. I spent 3 hours on that component, the refactor was done but I loose 3 important hours in something that was out of scope.
Don't get me wrong, there are moments when refactor or tweaking are necessary in order to continue with the task, but for the feature I've been doing it was not. If you want to try a new library or maybe change tons of code, think twice, Is this really necessary?
Communication.
It's key in a team. If you don't understand something, ask, if the product team gives you a design that it's not clever to you, ask the necessary questions.
And most important, when you feel the task or project you are working on is going to take you longer, don't wait until last day to announce this to your manager, yeah I know, we tempted to think that we are going to make it, even when there are two days left until the deadline and there is a lot of things to do, things that normally take you four or five days, we want to finish them in two. That's not possible, or maybe it is, but it will demand a lot of your time, you'll feel stressed, and chances are you won't finished either.
But if I ask for a deadline extension, I could lose my credibility.
There are times when you can't pass a deadline by one or two days and it's not really a big deal, but if a project it's very important, and many areas are going to be affected is this postponed, you need to communicate effectively and detail why this take longer than agreed. This will not take out your credibility, it will reflect your compromise to deliver excellent work.
If you choose to end a project in a hurry, maybe it works or maybe not, maybe it's buggy or you missed something important on the flow. If that is the case you could lose your credibility to deliver a task that didn't complete the requirements.
I really hope you find these recommendations useful and could improve your performance in any task assigned to you. Remember that, you never stop learning, it could take some time to know how to deal with estimations, and maybe you are going to fail in the process but learn from that for the next one.
Comics from here.
Top comments (15)
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..
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.
Well said 👍
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.
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.
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..
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.
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.
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.
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.
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,
From 25 years of professional development, I can safely say that estimation is a waste of time. Seriously, don't do it
If only life was that easy ;)
There are 2 resources I consider valuable in terms of software estimation:
I cannot recommend them enough - both for devs, as well as tech PMs.
It really is that easy. I wasn't joking
You'll get things done faster, and write better code
A good quote on the subject:
Taken from here