Some people might say that estimating is an art form, others consider it a skill, maybe even a science.
But the only thing we can all agree on is:
So, what's your story?
For further actions, you may consider blocking this person and/or reporting abuse
Top comments (7)
I had a 2 week long project (initial estimation) that lasted for 5 months.
Problems.
Not having a clear โ๏ธ vision of what the outcome would look like, I was able to muddle through but it was such a horrible ๐ฑ experience.
But now I am now armed ๐ช with the experience how to prevent from that ever happening.
It will be awesome if you could write and article about this!
Thank you for the suggestion, @nicolasguzca .
I will try if I can come up with an outline but might not happen if it comes down to talking behind their back.
Had to rewrite an app to make it more configurable.
Took us more than 6 months to have everything done and deliverable, the causes for that were:
On the other hand, rewriting that code really opened the project to many opportunities and tremendously eased its maintaining, so Iโm glad we did it in the end.
And yeah, as you may have guessed it: I recently made a mistake with my estimates. I was off by 4x the original one.
Now you can imagine what was the reaction from my managers...
Can't really go into much detail, but at least I would like to share with you all what I learned from this experience:
Dip your toes before you jump in
Make sure you clear any doubts, identify possible issues and try to find any dependencies you might have from other team members. This may require you to ask for more time to plan and come up with a better estimate.
Don't copy other's estimates
It's tempting to use other's estimates as a reference, specially when you are really new to a project, but try not to take them as is. Add some extra time for possible mistakes, take into account how unfamiliar you are with the codebase in comparison with him/her, extra learning time and assistance you might need.
Split big tasks
This is quite a common technique to deal with large tasks and it's totally viable, but remember to consider how the smaller parts will come together and if there might be any possible issue, specially when these smaller tasks can be done in parallel with others. Even "simple" things like merge conflicts can make your life a nightmare.
Never trust yourself
We don't always have a perfect day. Maybe you forgot something at home, had a fight with your family/friend/significant other. Heck, even messing up your coffee can turn you down, all these small things can build up and affect your timing.
Reveal yourself
It's better to say "I don't know anything about X and Y", because this will allow your manager to not only be aware of the consequences of assigning that task to you, but also try to help you overcome them. They might assign it to you and another developer to do pair programming along the way or let him/her know that you might need help and welcome any questions you might have in the future.
Being wrong with your estimates by a considerable time will directly affect the way your coworkers treat you, it's a matter of trust. Try to aim for quality over quantity.
If your estimates are off too often, your coworkers might even ignore your estimates because they no longer trust your ability to do so. Or even worse: set a hard date for you to deliver it, no matter what.
The example I thought of was a case where the work was split too much -- without accurate noting of dependencies within the small bits. It ended up taking 4 weeks to complete 1 user story since it actually had to do about 6 "little" features just to make it actually work and be testable at all.
What a great question!Mine is here:)
dev.to/ice_lenor/how-i-hired-freel...