One of the hardest things to do as a software engineer is estimation. Even the most experienced engineers curse their estimates, and almost everyone has had an experience with underestimating. In this post, I share a few things I’ve learnt and observed along the way.
Basics of Estimation
When you’re beginning to work on software estimation, I’d recommend working on listing sequential tasks needed to complete a feature – there’d be time for design, for each development step, integration into the system or product, unit tests, and for iteration at the end to iron out the bugs. Just write down a list of the things you need to do to go from your design to the finished code that’s ready to ship.
I would never recommend estimating anything as taking longer than three days. Break it down into multiple steps – I’ve found that engineers don’t understand what they’re doing if the step’s duration is three or more days. I’d also recommend never breaking down items into less than half a day — that’s likely false precision and makes the plan unwieldy.
Once you’ve got a schedule, do the work, and then ask how you did. If you’ve finished early, you’ve “sandbagged” — figure out why you underestimate. If you finished late, you’ll have had work-life balance issues to hit the date you promised or you held up the schedule – not something any developer wants . In either case, ask what didn’t I understand when I estimated? What types of work items do I over- or under-estimate? How could I break down an item into smaller steps so that I could get it right?
Good estimation always includes time to be a developer. Think about the meetings you will attend, how long code reviews take, and that there’d always be a day or two where you’ll be fixing production issues. I would recommend never calling those out separately – personally, I have typically added about 20% to each of my work items to account for the “down time”. To me, it doesn’t make sense to call these out separately – they’re part of the time that it takes from starting to finishing a work item, not something that happens at a fixed point in the development cycle. I am allergic to work items such as “code hardening” and “meetings”.
In case you’re wondering, I was guilty of frequent underestimation earlier in my career; that seems the more common mistake that developers make. I learnt that my gut estimate is always under by a factor of about 2.5. I’ve heard others say 2 or 3, and one guy who used to say e (2.71828183). I figured this out by doing post-morterms – I’d go back, learn from mistakes, and strive to improve.
I’ve noticed that senior engineers tend not to like the linear list approach. They tend to do more tasks in parallel, and estimation becomes more complex. They often jump around the tasks while they figure out how to unblock the next logical task in the list. Net they have lots of things brewing and incomplete. I’d still recommend writing down the tasks in a minimum half day, maximum three day list, and tracking how long you’ve spent on each one — even if you don’t burn through them in a linear way. Estimation up front is still important.
Estimation and Leading Small Teams
When I was a development lead, I used what I’d learnt about estimation to manage my team. I asked each developer to put their list of tasks in a shared spreadsheet. Every Friday, the developers would update the sheet with any new information, such as being ahead or behind schedule, or inserting or deleting work items. I used this to determine whether we’d ship on time, and to rebalance resources where needed to ensure we did. I also used it to understand who was good at estimation, and where we could improve. It turned out to be a good way to keep people open and transparent about what they were working on too — and helped us be more focused on great estimation.
Good luck estimating!