Agile Software Estimation Best Practices

Oct 25th 2017 (updated Apr 3rd 2023)

devpracticeagile

Estimating software development work is a crucial part of the development process, enabling teams to plan and prioritize work, set deadlines, and allocate resources. However, it can be a daunting task. In this article, we will explore some of the best practices for estimating work in software development teams.

Estimate in Relative Size

When estimating software development work, it is better to estimate in relative size rather than in absolute terms. People are much better at estimating size relative to something else, and using relative estimates helps in establishing a baseline for estimating future work.

"Bucket"/Group Similar Work

Building on the idea of relative sizing, grouping similar work into buckets can help in estimating software development work quickly, easily, and accurately. This method is especially helpful for new teams or projects where there is less historical context.

Prefer Precision over Accuracy

While accuracy is desirable from a planning point of view, it is much harder for humans to achieve. Instead, aim for precise estimates, which can be made "accurate" by applying an adjustment factor based on historical data. Don't waste effort and time trying to get people to give 100% accurate estimates.

Accuracy vs Precision

Understand what you're estimating

You can only estimate what you understand. Ensure that the ask is clear and that the team has the context for the work they are estimating. This will help ensure that the team is on the same page and able to provide useful estimates.

Break down larger work

Breaking down larger work into smaller, more manageable pieces makes it easier to estimate. It allows for more precise estimates and helps the team avoid being overwhelmed by the scope of the work. Ensure that the work breakdown structure follows the INVEST principles.

Estimate as a Team

Estimates by consensus are generally more accurate (as long as they don't bias one another). The team can discuss any differences in estimates and arrive at a final estimate together, leveraging the "wisdom of crowds" to improve the precision of the estimate.

Those doing the work provide the estimates

The people who will perform the work are the best people to estimate the work required to complete it. Involving the team in the estimation process promotes ownership of the work and provides an early exposure to what the work entails.

Estimates are not commitments

Estimates are a planning tool, not a commitment. When treated as a commitment, it can lead to overestimation, increased stress, lower morale, and less focus on delivering the work. Estimation should be used as a reference point for reflection, not a rigid commitment to deliver by a specific time.

Use Planning Poker

Using Planning Poker is an effective way to estimate work as a team. By keeping estimates hidden until everyone has provided their estimate, it can help avoid the "bandwagon effect" where people copy the most senior team member's estimate. It can also prevent the "halo effect," where people are drawn to something with a positive sheen to it.

Use Fibonacci Sequence for Estimating

Estimating larger work items can be challenging. The larger the work item, the more inaccurate the estimate becomes. Using the Fibonacci sequence can help reflect the challenge of estimating larger work.

By following these best practices, Scrum and Agile teams can estimate software development work effectively and efficiently, enabling them to plan and prioritize work, set deadlines, and allocate resources with confidence.

References