Stefan Wolpers September 21, 2021 TL; DR: Estimates Are Useful, Just Ditch the Numbers
Many people dislike estimating work items as estimates supposedly open the path to the misuse of velocity by the managers, reintroducing Taylorism, micro-management, and excessive reporting through the backdoor. To them, for example, the proponents of #noestimates, estimates conflict with basic ideas of agile product development such as self-management, becoming outcome-focused, or leaving the feature factory for good.
I like to suggest a different, less ideological approach: estimates are useful at the team level, just ditch the numbers. How so? Estimation of work items is a fast way for a Scrum team to figure out whether all team members are on the same page regarding the why, the what, and the how of the upcoming work. The numbers are a mere side-effect, probably still valid to inform the team, though. (Indeed, the numbers are not intended to be used beyond the team level.)
Estimating Leading to Micro-Management; the Legacy of Taylorism
Usually, the fear is that once a product or Scrum team starts estimating, the results will be normalized by the management, compared to other teams, and thus hold against them in the long run by establishing mandatory productivity for a Sprint, for example. Moreover, now that the team’s “velocity” has been set, it will be used to compare the team’s performance with other teams in the organization. Misappropriating an internal team metric might also open a path to stack-ranking teams pitching them against each other, leading to a more competitive and less collaborative environment.
In other words: estimating work and creating estimates leads straight back to the industrial paradigm thinking of Mr. Taylor and his supporters. Unfortunately, this ideology of the need to protect the organization from its workers—who managers expect to start slacking the moment they are not directly supervised—is incompatible with the idea of solving complex, adaptive problems and becoming a learning organization. (If you like to broaden your understanding of the precursors of Taylor’s “scientific management system,” I recommend reading Caitlin Rosenthal’s “Accounting for Slavery.”)
From Estimates to Velocity to Committing to Deadlines
“It’s Difficult to Make Predictions, Especially About the Future.”
Typically, a line of argumentation to object estimations as a team is as follows: estimates are by definition no precise calculation as no one can predict the future. However, based on previously aggregated data, see velocity, managers and stakeholders use the numbers to push a Scrum team to make commitments on scope and dates of delivery. This way, they ignore essential principles of working in a complex environment, such as self-management of the team or trusting that the team will do its best to create value for the customers.
While this line of thought maybe a valid concern, it is rather a sign for the dysfunction of the organization in question than the toxicity of estimates per se. Hence the consequence should not be ditching estimating itself, but addressing the lack of trust that is reflected in such an agile anti-pattern.
A successful way to creating trust between management and stakeholders on the one side and Scrum teams on the other side is regularly delivering valuable Increments. Getting to that level of proficiency requires dedication among the team members to understand why they are working on something, what shall be delivered, and how the Developers will technically realize it.
This approach starts way before estimating Product Backlog items at the end of the refinement process. On the contrary, it means including all team members in the product discovery process that feeds new work into the Product Backlog. It is about collaboration, inclusion, and giving everyone a voice in the process. If this teamwork approach is the standard, estimating work items is just the final confirmation that all team members are aligned on the why, the what, and the how. (If not, put in more work refining the work item; apparently, team members still have different perceptions of the upcoming work.) Thus, using a simple planning poker session, the team can mitigate the risk of complexity and inherently become better at delivering. And delivering creates trust among stakeholders. In that scenario, no one needs numbers. Therefore, just ditch them.
Conclusion
Don’t turn a technical procedure—here: creating estimates—into a scapegoat for the dysfunction of an organization. The root cause of the latter is a lack of trust, which you cannot address merely at a team level. Strive for the creation of a holistic, inclusive product creation process instead. Lastly, I am convinced that people will always “estimate,” whether they talk about it or not.
Are you estimating your work? Please share your learnings with us in the comments.
Business & Finance Articles on Business 2 Community
(47)
