Estimating
Estimating in software development involves assessing the size, complexity, and effort required to complete tasks or deliver features, typically to aid in planning and prioritisation. Estimating in software development is controversial because people are asking to predict the future and the challenges that we will encounter when building something completely new. However, it is a necessary activity to provide a relative gauge of task complexity so that we can effectively decide between different tasks and features.
Purpose
The purpose of estimating is to obtain a relative gauge of task complexity to facilitate planning and prioritisation, aligning team efforts with current objectives.
Context
Industry Context
Software development teams are often asked to estimate the length of time it would take to build a project. There are so many unknowns related to understanding the real intent of the requirements, the complexity of the solution, the skills of the team and the impact of all of the blockers in the process. Regardless of the caveats that development teams provide the estimates provided become the deadline for delivery. This leads to a number of problems:
Estimates mask the problems in the process: Team leads inflate estimates to account for the bias towards optimism in development and the fact that people are not coding 100% of the time. Project managers then add more time to account for the blockers in the process that the team will not be able to control. Finally, there is usually a buffer added for the project manager to be able to handle any unforeseen issues. Because teams are not incentivised to remove the blockers in the process, the estimates just keep growing resulting in product development taking longer and costing more.
Unrealistic deadlines lead to poor decisions: When the estimates are used as deadlines, the team is forced to make decisions that are not in the best interest of the product. As the deadline looms the team makes short term decisions that will lead to technical debt and poor quality.
Unrealistic deadlines lead to burnout: Pressure doesn't cause burnout, having no control over the situation and being unable to make a difference is what causes burnout. Hard deadlines, based on early-stage estimates, that don't evolve as the team learns more about the problem, lead to a situation where the team is forced to work long hours to meet the deadline.
ZeroBlockers Context
Teams are accountable for the outcomes they achieve. Estimating the relative complexity of different work helps to make decisions about what to work on next. The estimates are not used as deadlines but rather as a way of determining which pieces of work to focus on next.
Since the focus has shifted from meeting a deadline to achieving outcomes there is an incentive to remove the blockers that slow down delivery and improve the overall process.
Methods
| Method | Description | Benefits | Use Cases |
|---|---|---|---|
| Blink Estimation | A group of experts provides a rapid, intuitive estimate of the size, complexity, or effort required for a task or feature. | Enables rapid estimation without excessive analysis. | Release estimation |
Other Methods
| Method | Description | ZeroBlockers Opinion |
|---|---|---|
| Story Points | A relative estimation technique using a point scale to represent the effort required for tasks. | Proponents argue that story points are measures of relative complexity and not time, but in practice, a sprint has a point budget as well as a set time frame. Inevitably the points are translated into a sprint goal and now you have the same deadline problem. But as with contingency before, story points are up to the team to identify so it is easier to inflate the point estimates than to fix the underlying blockers in the process. |
| Planning Poker | A consensus-based technique where team members make estimates by playing numbered cards face-down to avoid anchoring biases. | Similar to story points, and quite often using story points, planning poker faces the same challenges. Estimates lead to deadlines, which leads to inflated estimates and poor decisions. |
| T-Shirt Sizing | Categorising tasks or features into sizes (XS, S, M, L, XL) to provide a relative estimate of effort. | T-shirt sizing is great because it is only a measure of relative complexity. But it doesn't help us to either reduce lead time or to gain a high level idea of the timeline to deliver a feature. |
| Three-Point Estimating | Considering the best-case, worst-case, and most likely scenarios to derive an estimate. | This can be effective but it takes longer than Blink Estimation. We believe that rather than asking one person to estimate the different cases, each person should estimate their most likely and then verify if these converge. |
Anti-patterns
- Turning Estimates into Deadlines: Using estimates as fixed deadlines, leading to unrealistic expectations and poor decision-making.
- Over-reliance on Historical Data: Using past projects as the sole basis for estimates without considering current project specifics.
- Groupthink in Estimation: Allowing the opinions of a few team members to dominate, overshadowing individual insights and leading to skewed estimates.