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.)
By the way, similar to the fact that you cannot “not communicate,” I am convinced that people will always “estimate,” whether they talk about it or not.
👉 Join the poll and the lively discussion on estimates on Linked!
🗞 Shall I notify you about articles like this one? Awesome! You can sign up here for the ‘Food for Agile Thought’ newsletter and join 33,000-plus subscribers.
🎓 Join Stefan in one of his upcoming Professional Scrum training classes!
📈 Join the Anonymous Poll for the Upcoming Free Scrum Master Salary Report 2022.
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.”)
Cannot see the form?
Please click here
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.
📖 Related Posts
Scrum First Principles — How to Elon Musk the Scrum Guide
Three Essential Agile Failure Patterns in 7:31 Minutes—Making Your Scrum Work #12
The Meta-Retrospective — How To Get Customers and Stakeholders Onboard
Download the Scrum Anti-Patterns Guide for free.
✋ Do Not Miss Out and Learn about Estimates: Join the 10,000-plus Strong ‘Hands-on Agile’ Slack Team
I invite you to join the “Hands-on Agile” Slack team and enjoy the benefits of a fast-growing, vibrant community of agile practitioners from around the world.
If you like to join now all you have to do now is provide your credentials via this Google form, and I will sign you up. By the way, it’s free.
📅 Scrum Training Classes, Workshops, and Events
See all upcoming classes here.
You can book your seat for the training directly by following the corresponding links to the ticket shop. If the procurement process of your organization requires a different purchasing process, please contact Berlin Product People GmbH directly.
If you like to learn more about estimating and sizing, consider attending Stefan’s Professional Scrum Master classes.
This discussion on the pitfalls of estimation and the legacy of Taylorism in the context of agile methodologies raises important points. We’ve observed that while estimates are essential for planning and budgeting, the way they are used can significantly impact team dynamics and overall project success. We advocate for a balanced approach where estimates are seen as tools for guidance rather than strict targets.
A great way of putting it, George!
Stefan, I’m grateful to you for this post (and, by the way, how you’ve impacted my life through your weekly newsletters). When I read your article, I was reminded of the quote by Zhuangzi, the Chinese Daoist philosopher:
“The fish trap exists because of the fish;
once you’ve gotten the fish, you can forget the trap.
The rabbit snare exists because of the rabbit;
once you’ve gotten the rabbit, you can forget the snare.
Words exist because of meaning;
once you’ve gotten the meaning, you can forget the words.
Where can I find a man who has forgotten words, so I can have a word with him?”
I would dare to amend the above quote based on your thinking:
“Estimates exists because of alignment;
once you’ve gotten the alignment, you can forget the estimates.”
Join the poll and a lively discussion with 100-plus comments: https://www.linkedin.com/posts/stefanwolpers_estimates-noestimates-agile-activity-6845693100594122752-Bn9p