A common theme I’ve noticed during my time in engineering leadership is that many engineers dislike estimating their work. Some dislike it so much that it causes them actual stress and anxiety. Though my personal philosophy is that nearly all work should include an estimate, I don’t think this should be a scary or stressful process.
Estimates can be as specific as an hour range, story points (for those using agile project management), or even a rough t-shirt size (small/medium/large). All of these types of estimates have pros and cons, but going through the exercise of coming up with an estimate has considerable benefits to development teams and clients.
The Benefits of Making Estimates
The biggest benefit to going through the process of coming up with estimates is it gives the developer a chance to dig into a task and identify risks or questions that may not otherwise be obvious. For example, changing the logout message on the application might seem straightforward, but after digging in a bit, you could notice that it gets the message from an API that has its own challenges in making updates which will take longer to update. It’s good to know that upfront before oversimplifying the task to set yourself up for success and let others understand an ask’s complexities.
A secondary (and likely obvious) benefit is to provide clarity. Clarity to the person requesting the task and clarity to managers and the rest of your team, if you work with a team. An example I always think of is when a client asked for some changes to a React application and estimated 8 hours, but when I dug into the code, it was much more complicated and took up 20 hours. The client wasn’t excited to pay for 12 extra hours and said they wouldn’t have asked me to make the changes if they knew it would take so long. Lesson learned – clients and teams use the information provided by an estimate to make decisions about whether to proceed with work.
My Estimation Philosophy
My personal philosophy on estimation is that sometimes we will come under estimates, sometimes we’ll go over estimates, and over the long run, they tend to even out. Accuracy with estimates improves with familiarity with a codebase, so it takes time for people to get to a point where they know a codebase well enough. This is why it’s essential to have somebody such as a project or technical lead review estimates and provide a gut-check. Better yet, making estimates as a team during a meeting can be a fun way to dig into a codebase and learn about the demons that may be lurking.
Some of the common fears I’ve heard come from a place of distrust with what happens when developers go over an estimate. It’s the responsibility of a manager to clearly explain what estimates are used for and the process for changing or communicating risks to an estimate so teams feel comfortable bringing up unforeseen challenges. I’d much rather have somebody speak up and let me know we underestimated a task when they are a few hours in rather than burn themselves out trying to achieve an unobtainable estimate.
From my experience, people rarely go over estimates because of incompetence but rather due to misunderstanding the requirements or codebase. If developers end up going over an estimate, it’s essential to view this as a learning experience and determine how to improve our estimates for the next task without adding too large of a buffer. Over time, the estimate should become more predicable.
There are times, however, when individuals do a poor job communicating why they are regularly going over estimates. This is usually uncommon, but it does sometimes identify when people may need some extra support to improve their communication or technical skills.
- Always create an estimate before you start to work on a task, and document that estimate (and the reasoning) clearly for others to see.
- Agree on a given estimation scale with your team or collaborators to your project. Do hours make more sense than t-shirt sizes? Make sure everybody is aligned and is estimating in the same manner.
- Utilize the project lead to gut-check estimates
- Communicate any changes to assumptions or estimates early and often with your team. Clear communication is the lifeblood of any project.