What's your worst estimate story?

Cover image by @rawpixel from Unsplash.

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:

No matter your skill level/years of experience, you will probably be wrong.

So, what's your story?

Comments

[Sung M. Kim]

I had a 2 week long project (initial estimation) that lasted for 5 months.

Problems.

1. 🔬 The scope was never defined - There was no "done" state.
2. 📝 Requests/Changes were never documented - steakholders kept on making changes not in alignment with previous requests. But having no documentation, I could not prove that the change request would invalidate all previous implementations.
3. 👩‍🍳 Too many cooks - There were multiple "managers" involved and each had a say on how to proceed whenever a new feature/change was needed.

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.

[Nick]

It will be awesome if you could write and article about this!

[Sung M. Kim]

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.

[Elarcis]

Had to rewrite an app to make it more configurable.

“Sure, the code is already well compartimented, it’ll be easy: 2 weeks and it’s done!”

Took us more than 6 months to have everything done and deliverable, the causes for that were:

• The time you’ll take to write everything is negligible compared to the time you should be spending on designing, testing, foreseeing complications and issues;
• Just because the code base is there but needs to be written differently, don’t assume that most of the work is already done.
• Complexity and development time rise exponentially the closer you get to a perfectly architectured design. Sometimes it’s better to not go for the cleanest SOLIDest, DRYest design and shave off a significant amount of time at the cost of one mostly unused feature.

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.

[Christian Vasquez]

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.

[ItsASine (Kayla)]

Split big tasks

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.

[Elena]

What a great question!Mine is here:)
dev.to/ice_lenor/how-i-hired-freel...