Estimating sucks.
It adds a lot of pressure and stress, is super hard to get right, and makes you feel like you didn’t do your job right if it goes wrong.
I’ve made a lot of mistakes with estimating in the past, and I’ve felt that pain too. Through those mistakes, I got a lot better over time and things go right most of the time now.
In this post, I’ll give you a succinct explanation to get your estimates right 95%+ of the time.
💡Estimation principles
Before showing the diagram, it’s important to know the principles behind it so you can pivot when needed.
Think in T-shirt sizes, not days (Small, Medium, Large, Extra-Large).
Avoid giving exact dates. Use ranges like 1-2 weeks. Larger estimates should have wider ranges.
State your assumptions: “I expect this to be done in 1-2 weeks, but it could go longer if this X unknown causes a delay.”
Break down medium/large estimates into milestones and individual estimates. Add them up then add additional buffer time for unknowns.
Call out changes in estimates as soon as possible.
Understand what type of estimate you’re being asked for
When it will be done by: Be extra careful. Consider external factors and bake in more time.
Whether it’s worth doing: The estimate can be less precise. Give a rough t-shirt size and call out assumptions.
🪄 The 95%: Magic diagram
📖 Textual explanation
I added this mostly for accessibility and mobile—so if the diagram already makes sense as is, feel free to skip this section.
You receive a request, typically from your Product manager or engineering manager. They ask, “How long will it take?”
First, you must understand why they want this information. Are they asking, “When will this be done?” or are they asking for a rough idea to know if it’s worth doing?
When it will be done by: Be extra careful. Consider external factors and bake in more time.
Whether it’s worth doing: The estimate can be less precise. Give a rough t-shirt size and call out assumptions.
The question is actually, “When will this be done?”
If it’s small, you can either say “1-2 weeks” or “by the end of the week.” Whichever makes the most sense based on your meeting schedule and what’s currently going on right now. The flow ends here.
If it’s a medium or large T-shirt size, we need to break it down.
It’s a medium or large T-shirt size. We add 3 things together
(1) The summed-up estimate of each individual piece we broke down
(2) Additional time factors such as…- How much time off are people taking?
- External dependencies. Are there 3rd parties?
- Who is working on it?
- How many people are working on it?
- Are there company holidays, events, or offsites?
- How hectic are meetings?
- What potential risks have been identified?
- What work is blocking vs can be done in parallel?
Usually, we can just use a blanket 50% of the broken-down estimate for this piece to account for unknowns. So if in part (1) we said 4 weeks, this would be 2 weeks.
(3) Some additional buffer based on how important accuracy is. Add more buffer the larger the project scope is.
Example: 4 weeks (broken-down estimate) + 2 weeks (50% of broken-down) + (2 weeks due to the importance of accuracy) = Roughly 6-8 weeks.If at any point new information or unexpected edge cases arise, bring it up with relevant stakeholders like your product manager or engineering manager.
🤔 The 5% - When the estimate was wrong
Using the diagram, we hopefully accounted for unknowns and edge cases already in our estimate.
However, sometimes that isn’t enough.
There are two ways estimates go wrong.
“We missed this”
You found code you think needs refactoring in order to ship the feature
You found an edge case you hadn’t considered
You realize the architecture you designed won’t work
There was a company offsite or set of company holidays you didn’t account for
Be cautious of the voice in your head telling you, “This isn’t too bad. We should still be able to hit the estimate.”
We often want to tell ourselves this so it doesn’t come back that we missed these things. I get it.
But it’s much worse to reach the deadline empty-handed than to warn about it ahead of time.
“This happened to us”
You or your team members got sick for a few days leading to a delay
There were a series of unexpected developer infrastructure outages because of migrations your Platform team is doing
It just happens to be taking longer to complete than you thought it would
Seeing these, you can see why having some buffer in your estimates helps account for unknowns.
The main purpose of the buffer might have been for unexpected technical unknowns, but it can also help meet the deadline for cases entirely out of your control.
What to do
In both of these cases, lean on sharing the effect of it on meeting the estimate.
💡 If it’s something minor, mention it in standup
💡 If it’s a larger issue, mention it in your project channel
Don’t overdo this. I’m not saying you should send a message out that because you had to rename a variable you might not meet sprint goals.
But lean on letting people know rather than not.
💡If you are > 50% confident you won’t meet the estimate, state that and give a new one you are confident about.
Takeaways
Here are the top 3 takeaways to close us out.
Buffer time is essential. You might have had it for technical unknowns, but it can be valuable for things outside of your control
Understand the underlying reason behind the need for the estimate. It can help you determine how to approach it.
When unknowns arise, call it out as soon as possible. It’s much better to call out a delay early on rather than come empty-handed on the day of the deadline.