As developers, we tend to be very optimistic and we often give lower estimates than we should. Even when working on a project with little amounts of pressure, we usually underestimate the time or complexity of a task.
There are many reasons that cause us to underestimate, and most come down to the old saying:
You don’t know what you don’t know.
No-one can always anticipate every issue that might arise, and there will always be times when even the biggest overestimate will be wrong, but making sure to keep that simple quote in mind will help you make better judgements when estimating work.
Let’s look at a few of those areas that can trip you up and how to avoid them:
Lack of understanding
Whether it’s new technology, new codebase or new business requirements, there will always be times when you don’t know things. This is usually the reason why we underestimate and this is especially true for more junior developers.
The solution to this one is really simple — take time and clarify:
- Define what needs to be done to complete the piece of work
- Plan how you will go about doing the work with the technology being used
- Identify any potential blockers that you might run into
This isn’t going to be 100% effective every time, but spending that little bit of time can help you find some of those issues that you didn’t know about. Utilise the resources you have available. More experienced developers, or people with more detailed knowledge in a certain area, can provide guidance on potential issues that a lot of planning may not have prepared you for.
Changing business requirements
It’s pretty likely that whatever you’re working on depends on the business requirements, and sometimes those requirements have to change for one reason or another. This can be very frustrating, especially when the requirements are coming from people with limited technical knowledge who don’t understand how those changes affect the amount of work required (classic xkcd).
Since we can’t change the fact that requirements will always change at some point, we have to make sure to be clear with our stakeholders. Whether we’re working in a team or alone, we have to make sure to clarify what work is to be done as part of the task and communicate clearly that the estimate is for that work and any changes to requirements could affect that. If requirements do change, we should always take some time to properly estimate the impact of the change on our original estimate.
Outside influences
If you’re working in a team or using external services, you’ll know there can be the occasional downtime or bug. These can become blockers if they impact the work you’re doing, and if you’re dependent on someone else to fix the issue then there can be a big risk to your estimate.
There’s a couple of ways to reduce the impact when these blockers inevitably come up:
- Add in some padding to your estimate to allow yourself some extra time in case of small blockers.
- Try and identify any potential blockers before estimating.
- Raise the blocker to make the relevant stakeholders aware of risk to the work being delivered.
There’s no bulletproof way to estimate complex work with so many possible unknowns, so we as developers need to take a little more time to consider the potential issues and make sure to communicate to stakeholders as blockers come up.
