One day you are deep into a refactor, or several layers deep chasing a bug, when suddenly you get interrupted by a message from your manager or the PM, asking how long the task will still take. The initial estimate you gave is long past, and they need an update to adjust the sprint/roadmap/timelines.
You find yourself in a bind. The task turned out to be way hairier than you imagined, and you still don’t know how long it’ll take to finish. Nevertheless, you must produce another g̶u̶e̶s̶s̶ estimate.
I’ve been in this position countless times in my career, and it’s never a fun place to be. You know you only have yourself to blame, and from that point forward, your best-case scenario is to get it done late.
Although you can’t fix the past, there are things you can do to avoid this situation entirely.
First, accept that nobody in your team knows how long a given task should take, including you. Accurate estimates are usually only possible when you spend hours reviewing the details, and even then, you can find problems later on that you couldn’t predict.
Unfortunately, managers, PMs, and executives expect you to know that. It is unfair, but that’s the reality. Saying you don’t know is not professionally acceptable, but you can prevent painting yourself in a corner with these strategies:
1. Give a band estimate instead of a single number
The uncertainty is there, you don’t have all the information yet, and it is in your best interest to let that be clear. Estimate the best and the worst case scenarios with two standard deviations or ~95% accuracy.
If the estimate is too broad, you will get a push-back to narrow it down, but that’s good news. The task is hard to estimate and needs more attention.
2. Explain which factors are creating uncertainty
List the risks that could derail the plan. Explain what you don’t know that made the estimated band so large. Describe how you can narrow things down and how long those will take. Suggest doing those first if the band is unacceptable.
3. Suggest breaking down the task
Always try to break big tasks into smaller ones as there’s no downside and many upsides. That also applies to estimates.
In some cases, managers and PMs care more about the predictability of their timelines than how fast they get done.
If something is too uncertain to estimate, it means it’s too big, too unclear, or both.
4. Add fat to your response
It’s much better to be pessimistic when planning and delivering a task faster than to be optimistic when planning and failing the deadline. It is wise to add some fat to your response.
Managers often double the time you estimate when communicating upwards, for the same reason.
5. Communicate big problems as soon as possible
If you discover a problem that invalidates your estimate, raise a yellow flag ASAP. Why?
- Team members might have dealt with something similar in the past and could offer pointers.
- It might be a technical limitation of your environment that you can’t fix.
- It could be something that renders the task too costly to do. The list goes on.
If you communicate it quickly, you will adjust expectations and give people time to react. Your team might be relying on your task getting done.
They will appreciate the heads-up!
Conversely, if you silently try to get it back on track, you buy all that risk for little gain.