Suck Less at Estimations as a Software Engineer
As a software engineer you’re going to be ultimately judged on 2 things:
- Did you deliver?
- Did you deliver on time?
Your manager wants to know when they can expect the feature. Marketing wants to know when they can advertise it. The CEO wants to know when it will make money.
Unfortunately, software engineers universally suck at estimating how long it will take to do something.
Humans Suck at Estimating
Actually, everyone is pretty bad at estimating.
- We’re optimistic
- We have focus bias (focusing on one thing over other factors)
- We procrastinate
So if we suck at estimating, how do we get better?
There’s not much you can do when you get a feature that’s been estimated ahead of time. Here’s how I retroactively estimate the length of time to complete a feature:
Step 1: Break it Down
Your feature request will tell you what is expected but not how to implement it. This is where things can get messy.
The request is for a button that calls an API when clicked.
Easy right?
You confidently predicted it would take a day.
What about tests? Styling? Local testing? PR cycling?
Write out every step that needs to be completed in order to move this ticket to “DONE”.
Assume there will be some hidden complexity in steps like testing or the PR. For example, expect that your PR will not be done in 1 pass and you will have some changes to make based on the reviewer’s comments.
Step 2: Estimate the Small Steps
You may have underestimated the overall feature. That’s OK. Now that we have all the small steps needed for the request we can get a realistic idea of how long this will take.
Next to each of the small steps you wrote in Step 1 — add a time estimate. Use quarter or half days as units of estimation.
Perhaps you’re one of those lucky developers that has no meetings or other obligations. The rest of us will rarely get more than 3 hours of uninterrupted time to code which is why I like to use partial days to measure effort rather than hours. This way you will naturally pad the times to accommodate those “do you have a minute” interruptions.
Step 3: Combine the Small Steps into Daily Deliverables
Now you have a clear picture of what is needed and the padded times for each individual effort.
- Styling the button — 1/4 day
- Triggering the API — 1/4 day
- Tests — 1/2 day
- PR (assuming some back and forth between reviewer and developer) — 1 day
- QA — 1/2 day
Total: 2.5 days
Original Estimate: 1 day… oops
If you start on Monday you should reasonably expect to have this feature completed by Wednesday.
If a small step in your estimates drags on longer than anticipated you can expect to delay your delivery date.
Step 4: Be Honest With Yourself and Others
You originally said Monday. Now you understand that this ticket may take you through Wednesday… oops.
You should communicate potential delays early and often. It’s better to say a feature will be delivered on Friday and then actually complete it Wednesday.
The worst thing you can do is to give unrealistic, misleading or generic updates.
“Uhhh, still working on it.”
Working code delivered on time will beat great code delivered late.
Use Your Previous Estimates in the Future
Once the feature has been delivered you have an actual unit of time to measure against similar tickets.
Next time the manager gets a request for another button that calls an API and someone confidently says it will be completed in 1 day, you can suggest, based on previous experience how long it will actually take.
Read this post and more on my freakin’ site at yourcodecoach.com
