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.
...
For further actions, you may consider blocking this person and/or reporting abuse
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