How to Avoid Fear When Giving an Estimate

All projects usually start with careful planning regarding technologies, features, architecture and requirements, and of course, giving an estimate. Naturally, these might change once the development process starts. In those two states of “an already started” and “to be started” project, the key aspect of this whole operation would be estimating. Questions like:

Such topics are usually pretty common when giving an estimate. We will traverse through different tips or scenarios, which would help both sides when discussing any of the questions above.

With or Without Giving an Estimate

Before we dive deeper into the specifics, let’s start with a simple example. Suppose you have invited some friends to spend the weekend together and they have told you they would come without telling you when. Unfortunately, this would mean that your weekend is booked entirely although they would come for an hour or two at max. Another worth mentioning case here is that even if you knew the time they would come, it is still uncertain whether they would have this precise timing or come a bit later or earlier.

In this example, we have shown the two most common issues:

Both of those issues have to do with the word “estimation”. If we take in advance the definition from Cambridge’s dictionary, it means “a guess”. In a guess, there is always a margin of error, which can either be small or large. This margin of error directly corresponds with the expertise of the one giving an estimate.

Breaking the (pr)ICE

Giving an estimate in detail requires solid knowledge of the product design and the technologies that developers use in the project.

Those estimates are crucial as the client would know what a certain feature would cost. Sometimes, they would not know the technical requirements for the completion of a specific task. In the end, clients only see the tip of the iceberg. In our case, whether the feature is present or not and whether it works properly. Usually, this is the part where fear takes its place. The developer would be either scared not to say too many days as they might feel the client would be ripped off. The other option is to give fewer days than it would take to finish the specific task. However, no one would like to be ripped off or have unrealistic expectations, so what should we do?    

Firstly, when giving an estimation the best approach, in my opinion, is to evaluate the task per person (even if you are an enormous team). Ignoring the seniority, we would give an estimation of what a single person would be able to do within the given period. Sadly, this is rarely enough – from the first example that we’ve given, we could use this margin of error as a “buffer”.

This buffer would consist of “extra days” that could be either used for development if an implementation gets tricky. Alternatively, developers could also aim for an earlier release if they finish earlier. But how do we really determine those extra days? We could use a static 20% from the estimations of any task. Let’s say we evaluate adding a new button with some complex logic to a “10 days task”. Then, our buffer would be 2 extra days, making it a total of 12 days of evaluation. Having this buffer ensures that both sides are in favour of the given estimate – something like insurance.

Failing to Meet an Estimate

What happens if you fail to meet a given estimate for task completion? It usually comes to that the time interval was not enough or something came up. Both of these are normal outcomes but they need corrections. In the end, if some of your estimates are not on the right track regarding timing, this might be due to your not unrealistic assessment of your knowledge in the field or the technology used – both options mean that you or your team require more research or more time.

Clients would prefer to have a solid working product with minimal cost and maximum value. At the same time, they are ready to pay for an extra day of work (if required) just to precisely finish and test a specific feature, which is why asking for an extra day or two is always an option.

Another option here is to cut some features that are not as mandatory or as required to meet MVP demands, for example. After all, as long as the work is of maximum quality, failing to meet a task’s completion time, could have many explanations. But it is usually just another lesson learned regarding the estimation. Remember it is human to be wrong from time to time.

In Conclusion

Giving an estimate doesn’t only play a huge role in project management but also in our everyday lives. Whether it would be for dinner, a fitness workout or just grocery shopping – we all operate with time, budget and effort estimates. Furthermore, in the IT-sphere they help clients measure features’ cost and the developing team’s efficiency. Plus, it could also provide as realistic dates for release as possible. This is why developers must make thorough detailed research before giving an adequate estimate. 

The best option to meet the client’s demands or at least to have insurance is to use the strategy with a buffer. Although it increases the time for task completion, it reduces the risk of failing to deliver features/ products. In the end, the fear of giving an estimate has to do with the budget. You might need to change your initial one by requiring more days, thus increasing the cost of the product. Nevertheless, keep in mind that it’s human to be wrong at times and estimates can never be 100% precise. Despite that, it is important to stay professional and make thorough research beforehand. This way, you reduce the error margin when making a new estimation so that it gets as realistic as possible.

Book free consultation and a Dreamix representative will contact you directly.