Learn how to Estimate Properly

What you'll learn

The Importance of Accurate Estimates

Estimate vs. Commitment

Common Estimate Breakers

Strategies for Padding Estimates

A critical function of any software engineer’s job is to estimate the amount of time required to complete a task. This skill, is one that truly sets apart junior from senior engineers.

When you as an engineer provide an estimate to your manager, you are then held accountable to meet the expected deadlines that you put in place. Too often, I see engineers missing deadlines and having projects take longer than estimated. The excuses given for why an estimate was not accurate ranges all over the board from project scope creep, delays in deliverables being given to the engineer as well as a longer than expected testing time being required for the future.

Right or wrong, the blame for missing the estimate falls on the software engineer.

How then, as a software engineer, can you properly estimate the amount of time required to deliver your project or feature?

Estimate versus commitment

Let’s look at a common exchange that often happens between and a manager.

Manager:  How long with this feature take?

Engineer:  At least 6 weeks.

Manager:  That’s way too long - we need it done within the next three weeks.

Engineer:  I can do it in three weeks if we remove X, Y and Z.

In this exchange, the manager was actually not looking for an estimate. Rather, the manager was looking to get a commitment to meet a specific deadline. As an engineer, we need to recognize when we are being asked for an estimate versus a commitment.

When a commitment is being requested, the deadline associated with that commitment is often non-negotiable. If a task will take six weeks it is unrealistic to expect that we can accomplish it within three weeks. So then how do we communicate that that deadline cannot be met. One of the best ways is to offer what can be achieved with in the deadline timeframe and explained that some functionality might have to be left off. The manager can then make a decision that determines which is more important meeting the deadline or having the project be completed properly.

Estimate Breakers

What are the factors that break down an estimate and cause it to become invalid? Some of the most common are listed below:

1. An addition or change to the project definition or scope.
2. A delay in delivering a required dependency such as a piece of art.
3. A longer than expected testing phase and/or more bugs than anticipated.

At first glance it might be hard to understand or see how we can account for these issues when providing our estimates. However as software engineers, we need to properly evaluate the complexity and associated risks of the project we are creating. This includes providing an estimate on a feature designed that is incomplete and might be subject to a lot of potential changes. Or a feature that has a lot of required dependencies and can easily be delayed.

Depending on the tendencies of your project team, a certain feature that has high risk of feature’s scope changing, delays and deliverables and a potentially longer testing cycle may be the normal or abnormal to your development cycle. In either case we like to apply a padding to our time estimates. The larger the risk a certain feature has the more padding that we often attached to it.

Project Scope

Whether or not a feature will be susceptible to changes within its scope often vary from team to team. If your team has a tendency to spend more time in the project concept phase before handing a feature off to the developers then there is less likelihood of issues occurring around project scope. By contrast if your product designers often rush the project concept phase then there is a higher chance of your features getting change requests while they are in the development phase.  Look back at the last few projects that you’ve worked on and calculate out how long the project took versus how many days were added from changes. From a general rule, we apply a 5% padding to an estimate to account for changes. If a project is estimated to take 10 days for the developer then there is high likelihood that an extra half a day will need to be added to account for questions or changes that are worked out with the project manager.

Dependencies

Generally speaking, a developer should not have to account for delays in dependencies when providing estimates. So the need for this depends on the status and efficiency of your team. If your team is used to working with dependencies and potential delays, then there is a high likelihood that the dependency delay is already accounted for in your project timeline. However if your team is not used to working with dependencies and potential delays, then it could be the case that a delay could severely impact the deliverable.

Accounting for a delay in your estimate may not always be required. It should always be stated and brought out and clearly defined where in your development the dependency lies. For example, if you have a 10 day feature but can only accomplish the first two days before the dependency, then you need to spell that out when providing your estimate. You can do this by breaking it down into two pieces. The first piece takes two days and has no dependencies. The second piece will take eight days and can start whenever the dependency is resolved. In this manner you are providing an estimate from the time that you are unblocked and not an estimate from the time that the project starts.

Time for Testing

From a general standpoint, most features can use the 10% rule when it comes to estimating the testing cycle. If a feature took the developer 10 full days to develop, then it will probably require a full day of testing by the QA team. There is also high probability that the developer will also take one full day to either assist the QA team or respond to bugs raised by the QA team.

Wrapping it Up

Proper estimating does take time to develop as a skill. Estimate padding is also a technique that varies from team to team. Development teams that work very far ahead of their production cycles often don’t need to pad estimates as much as development teams that develop in very short production cycles.