Techniques to Improve Project Estimation

Written by krishnansrinath | Published 2022/11/01
Tech Story Tags: software-development | project-planning | software-cost-estimation | agile-software-development | project-estimation | agile-estimation | project-management | software-engineering

TLDREngineers undervalue estimation as a skill. Poor estimates can be costly, feeding into poor business decisions. Think of estimates as a probability distribution. Avoid committing to a number without understanding the details, and tasks involved. Use historical data to validate estimates improves accuracy. Allow the person doing the task to make the estimates. Review estimates as a team. Good estimation skills lead to better planning, A better plan will determine whether a project’s targets are realistic enough.via the TL;DR App

We’re often asked, ' How long do you think it will take to finish the project?’ As engineers, we like to build things. Building things, seeing things work and getting things done excite us. Engineers undervalue estimation as a skill. Poor estimates can be costly, feeding into poor business decisions. So, how do we do estimates better?

Here are some techniques to improve the estimation

Think of estimates as a probability distribution: We treat an estimate as a “prediction that has a non-zero probability of coming true”. Remember we operate with imperfect information when we start the project. We should consider our estimates as probability spanning best and worst-case scenarios. So, instead of saying the feature will finish in 8 weeks, we say there’s an 80% chance of the project completing in 8 weeks, and a 20% chance project will finish in 10 weeks.

Avoid anchoring bias: Anchoring bias occurs when people rely too much on first information or pre-existing information to make decisions. For e.g. if you see a T-shirt that costs $300, then see a second one that costs $100, you are prone to see a second T-shirt as cheap whereas if you’ve merely seen the second shirt priced at $100, you will not view it as cheap. The anchor - the first price that you saw unduly influenced your opinion. A similar effect happens in the project. A manager may ask for a quick ballpark estimate. Avoid committing to a number without understanding the details, and tasks involved. A low estimate (usually an underestimate) can set an initial anchor that makes it hard to establish a more accurate estimate later on.

Break the project into granular tasks: When estimating a large project break it into small tasks, and estimate each one of them. Breaking the project into small tasks is a reflection of your understanding of what’s involved. The more granular a task’s breakdown, the less likely for a surprise later.

Allow the person doing the task to make the estimates: People with different skill sets and levels of familiarity with the codebase. What takes one person to complete a task might take another person three hours to complete the same. As much as possible, have the person who will work on a task do the actual estimation. An additional benefit of doing this enables more team members to practice estimation skills.

Validate estimates against historical data: If you know historically, you tend to underestimate by 25%, then you know it’s worthwhile to scale up your overall estimates by 25%. Using historical data to validate estimates improves accuracy.

Review estimates as a team: Estimation is hard. We have a tendency to overlook, and cut corners. By reviewing estimates as a team, we have others that may have knowledge or experience to challenge our assumption and highlight gaps or incomplete estimates. This helps increase accuracy.

Project estimate is difficult to get right, and many of us have learned the hard way. The only way to get better is by practicing. Start with estimates on a smaller project where the cost of poor estimates is lower. By practicing on small projects, you can apply this skill on larger & high-risk projects. Good estimation skills lead to better planning, A better plan will determine whether a project’s targets are realistic enough.


Written by krishnansrinath | Product builder | People Developer | Engineering Management
Published by HackerNoon on 2022/11/01