Published on

Estimation Bias

Authors
  • avatar
    Name
    Estimator Tool
    Twitter

During the planning of work we might ask for an estimation for a feature (t-shirt size/story point) and in order to improve the accuracy of that estimation we will then ask a different member of the team to estimate the same feature. If the two estimations are very different, we then have a discussion around why that might be and try to come to an agreement on the true value of the estimation. This is very typical of practices like planning poker which are very common in agile teams.

The problem with this approach is that there is an inherent level of subjective interpretation built into this process because two people might express the same idea differently due to their experiences, different methods of thinking (convergent vs divergent thinking), perspectives, communication styles, and contextual influences.

This can lead to friction amongst team members and drag out the process of planning a lot longer than it needs to be and inevitably we spend a lot more time talking about the estimation than actually doing the work.

A useful way to remove the subjective interpretation from this process is defining a framework by which everyone involved in planning can make an objective estimation based on key factors that impact the delivery of any piece of work. This will in turn reduce friction amongst team members and speed up the planning process while also opening the door to healthy and productive discussions.

Key factors that impact the delivery of software

This might vary from team to team, however based on years of experience of building software (successfully and also failing). These are the key factors that will impact how small or how big a feature/project might be

  • History - Has this work been done before

  • New or existing technology - Are using new technology we are not familiar with

  • Dependencies - Do we have dependencies on other teams (internal/external)

  • Level of architectural change - Will the work require a significant architectural change

  • How big is the work - Will it require big or small changes to existing functionality

Check out the estimation tool to see how this might work in practice