Estimates in software projects are neither always a good nor bad thing, but they can be very prone to abuse and helping dysfunctional behaviors to spread. The most obvious of these is with teams who are trying to adopt agile in the context of an organization that is much more traditional, where management can have a tendency to pounce on any numbers they can get their hands on and try to use them to form big plans. One of the core tenets of the agile mindset is that even the best plan rarely survives prolonged exposure to reality, and instead of getting hung up on planning, a more healthy approach is to embrace that uncertainty and adapt to change. In my experience, estimates in the wrong hands can easily become “quotes” or “deadlines”, and for that reason among others I believe that many teams would be better in the long term with no estimates than with dysfunctional estimates.
To make estimates genuinely helpful to a team, they have to be treated for what they are – estimates. In a healthy team, some stories will be easier than originally estimated, and some will be more difficult. That’s ok, it’s kind of the point of them being estimates; the team can look back and for example might see that they were unable to recognize a particular complexity, or celebrate an ingenious approach that led to perceived complexity being avoided, and refine their mental model of the project as needed. Estimates tend to work better when they are treated as relative, and have no “conversion chart” to time. Unfortunately, human nature means that most individuals will tend to construct their own mental conversion chart, because it’s an easy universally understood currency.
One of the best teams I’ve worked with came up with a great approach which was to separate the estimate into two halves – risk and effort. In this model, effort was how time-consuming something was perceived to be, while risk was an indicator of how confident the team felt. Something that the team had done before but took a long time would generally be scored as high effort low risk, while something that seemed like a small task but that nobody knew for sure how they’d go about it would be low effort and high risk. This team then (reluctantly!) converted this to a number, purely for aggregation purposes, to compare the total with previous iterations. However, crucially, they took the numbers with a large amount of skepticism and made their own judgement. For example if a proposed sprint contained a low total number, but all of the stories were high risk, the team would often make a judgement call to leave a story out. After all, if the team found as they delivered that they had capacity, they could always add it in again later, and it was better for both the team and for stakeholders to set the expectation early rather than to go into an iteration with lower confidence.
A crucial dynamic that this hints at is that in this particular organization the team were trusted absolutely by stakeholders. The team acted responsibly, by making judgement calls, and volunteering “bad news” in the form of sprints that could have been perceived in less healthy organizations as being light on content. The stakeholders trusted that the team knew what they were doing, and after seeing plenty of examples of the team pulling in extra work when things went well, they also understood that there would also be times when things wouldn’t go as smoothly in reality and not everything would be delivered. The team would also freely re-estimate as soon as they perceived that the original estimate was wrong, for example if they discovered something. By explicitly describing estimates with “risk”, the stakeholders had total visibility of the team’s interpretation of the work, and there were no surprises.