Development Estimation Mistakes You’re Probably Making

Voiced by Amazon Polly

There are a lot of things teams do every day. These everyday activities can vary somewhat depending on project roles, methods used, and workflows maintained. However, there is one thing that can rarely be ignored — estimations.

You can always elect not to use them. (The #NoEstimates approach exists for a reason.) Still, if you do use estimates, no matter what you use — story points or working hours — one of the things that makes good developers is the accuracy of their estimations. That’s because inaccurate estimates can become an actual bottleneck that will have a substantial impact on project plans.

The following summary of the most common estimation mistakes comes directly from my experience working with different teams on various projects.

task requirements

1. No Cross-review of Task Requirements

When you have a team that takes care of, say, mobile app development, it usually consists of developers who are working with different platforms. This always means that the quality of their cooperation is one of the key factors in your project’s success. If the backend developer has no idea what the iOS developer needs or vice versa, it can easily lead to an unpleasant situation. For example, consider a situation in which the backend developer did their work, but it suddenly turns out that the iOS developer needs something else to do their part of the job. Due to a lack of information, we have received false estimations. Now, the task needs to go on a new “To Do — In Progress — Done” cycle and precious time is lost.

To avoid this mistake, it’s crucial to make sure that all team members are on the same page. Have them do a cross-review of the technical requirements.

research

2. No Time for Research

It’s no secret that estimating can be pretty tough, especially if the task is entirely new to its assignees and they have never done it before. In this case, a project manager or Scrum Master usually has two options: Request the estimation right away — which will undoubtedly be based on a pure guess — or set a timebox for investigation. Doing the proper research will reduce the risk of false estimates, and may even affect your understanding of whether you should do the task. It may turn out that it is better to update the project’s priorities in accordance with the task’s value from the business’ point of view relative to the resources (i.e., the time and effort required from the team) needed to complete the task. For example, research may help the team understand that the business value of developing a certain feature is simply insufficient to justify the team spending so much time on it.

Priorities

3. No Priorities Assigned

Product development is always about managing time and scope. If you do not assign priorities after the task is decomposed, the team — which is in this case doing tasks one by one — may waste time on something less important that could be done later, instead of focusing on the most significant tasks. Also, if the task scope is ambiguous and you have a limited time frame before release, priorities play the role of a helping hand when you have to decide what can be kept for later.

decomposition

4. No Decomposition of Features and Stories

Decomposing — the process of subdividing tasks into smaller, more manageable components — often seems like something that may just slow you down on your way to providing the estimations needed. Once, one of my teams thought the same.

A day before we started our first sprint, we discussed a story that, according to their estimates, seemed huge. There were no questions — only a massive amount of time requested for its implementation. Then, I asked them to help me decompose it. Within fifteen minutes of discussion, it turned out that the story was not that big after all, and we easily managed to finish it within the sprint.

In this situation, decomposing helped us to specify the requirements, understand the parts the task consisted of, and clarify the risks. Also, when the task was taken into development, the developers had a clear plan of what should be done. That clear understanding helped us tremendously in providing accurate estimates.

The prioritizing mentioned above goes hand in hand with the need to decompose large stories down into smaller ones. This video breaks down these concepts and explains how to make it happen.

estimating

5. Estimating in a Vacuum

Daily estimations make assumptions about the assignee’s expertise, experience, and understanding of possible risks. Still, proper estimating cannot be done in vacuum. The team should always be made aware of important business targets (e.g., attending an expo with an MVP for a demo by a certain date). This knowledge allows you and the engineers you are working with to plan towards these targets effectively, staying ahead of the game.

estimates

6. Treating Estimates as Final Values

Even when all of the above is said and done, there is one more important thing to be mentioned. Estimations are always provided based on assumptions — yours or your colleagues’ — and treating them as final, super-reliable values may not lead to the best results. After all, it is well known that project management is a realm of high uncertainty (as evidenced by the classic software “Cone of Uncertainty” problem, which describes how the amount of uncertainty changes throughout a project). Accordingly, this is a consideration that you should always keep in mind, staying ready to adapt as needed.

 
 

previous post next post
BACK TO TOP >