Useful Estimates: Ditch the Numbers

TL;DR: estimates can be helpful, but get rid of the numbers

Many individuals hate estimating work items because estimates are seen to open the door to managers misusing velocity, reinstating Taylorism, micromanagement, and unnecessary reporting. Estimates, for example, clash with fundamental agile product development principles like self-management, being outcome-focused, or abandoning the feature factory for good, according to proponents of #noestimates.

I prefer a less dogmatic approach: estimations are helpful at the team level, but leave the numbers out. What do you mean by that?

Estimation of work items is a quick method for a Scrum team to see whether everyone is on the same page on why, what, and how the future work will be done. The figures are just a side effect, but they are likely to be useful in informing the team. (In fact, the statistics aren't meant to be utilized at a higher level than the team.)

Taylorism's legacy: estimating leads to micromanagement

The concern is that once a product or Scrum team begins estimating, management will normalize the outcomes by comparing them to other teams, and therefore hold them back in the long term by imposing required productivity for a Sprint, for example. Furthermore, the team's "velocity" will be used to compare the team's performance to that of other teams in the company now that it has been established.

Misusing an internal team measure may lead to stack-ranking teams and pitting them against one another, resulting in a more competitive and less collaborative atmosphere.

In other words, estimating work and generating estimates harkens back to Mr. Taylor's and his followers' industrial paradigm thinking. Unfortunately, the desire to shield the company from its employees—who management anticipate to begin slacking the minute they are not closely supervised—is incompatible with the concept of addressing complex, adaptive issues and becoming a learning organization. (I suggest Caitlin Rosenthal's "Accounting for Slavery" if you want to learn more about the forerunners of Taylor's "scientific management system.")

Estimates, velocity, and sticking to deadlines

The following is a typical line of reasoning used by teams to oppose to estimations: estimates are by definition not accurate calculations since no one can foresee the future. Managers and stakeholders, on the other hand, utilize the statistics to urge a Scrum team to make promises on scope and delivery dates based on previously collected data, see velocity.

They disregard important concepts of working in a complicated environment in this manner, such as team self-management and believing that the team would do its best to generate value for consumers.

While this is a legitimate issue, it is more indicative of the organization's instability than of the toxicity of estimations in general. As a result, the solution should not be to abandon estimating altogether, but rather to address the lack of confidence that is represented in such an agile anti-pattern.

Regularly providing useful Increments is an effective method to build confidence between management and stakeholders on the one hand, and Scrum teams on the other. To achieve that degree of competence, team members must be committed to understanding why they are working on something, what will be delivered, and how the Developers will implement it technically.

This method begins long before the Product Backlog items are estimated at the conclusion of the refining phase. On the contrary, it entails including all members of the team in the product discovery process, which results in additional work being added to the Product Backlog.

Collaboration, inclusiveness, and allowing everyone a say in the process are all important. If this approach to collaboration is the norm, estimating work items is simply a last check that everyone in the team is on the same page about why, what, and how. (If not, spend additional time refining the work item; it seems that team members' views of the forthcoming task are still differing.)

As a result, by utilizing a basic planning poker session, the team can reduce the risk of complexity while also improving their ability to deliver. Furthermore, delivering builds confidence among stakeholders.

No one needs numbers in such situation. As a result, just toss them out.

Conclusion

Don't make a technical procedure—in this case, estimating—the scapegoat for an organization's dysfunction. The underlying reason of the latter is a lack of trust, which you can't solve just by working in a team.

Instead, strive to create a comprehensive, inclusive product development process. Finally, I am sure that individuals will always "estimate," whether or not they express it.

Thanks to Stefan Wolpers at Business 2 Community whose reporting provided the original basis for this story.