Estimates Are Useful, Just Ditch the Numbers

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.)

Estimates Are Useful, Just Ditch the Numbers — Berlin Product People GmbH

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 Hands-on Agile Meetup Community — Berlin Product People GmbH

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.


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.

Join the Hands-on Agile Slack Group, Learn more about the Developers Code Fallacy

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

You can secure your seat for Scrum training classes, workshops, and meetups directly by following the corresponding link in the table below:

DateClass and LanguageCityPrice
🖥 💯 🇬🇧 May 7, 2024GUARANTEED: Hands-on Agile #61: Toyota Kata Coaching for Agile Teams & Transformations with Fortune Buchholtz (English)Live Virtual MeetupFREE
🖥 💯 🇩🇪 May 14-15, 2024GUARANTEED: Professional Scrum Product Owner Training (PSPO I; German; Live Virtual Class)Live Virtual Class €1.299 incl. 19% VAT
🖥 🇬🇧 May 28-29, 2024Professional Scrum Master (Advanced) Training (PSM II; English; Live Virtual Class)Live Virtual Class €1.189 incl. 19% VAT
🖥 💯 🇬🇧 June 6, 2024GUARANTEED: Hands-on Agile #62: From Backlog Manager to Product Manager: From Outputs to Outcomes w/ David Pereira (English)Live Virtual MeetupFREE
🖥 💯 🇬🇧 June 13-July 11, 2024GUARANTEED: Advanced Product Backlog Management Cohort Class (PBM; English; Live Virtual Cohort)Live Virtual Class €399 incl. 19% VAT
🖥 💯 🇬🇧 June 25, 2024GUARANTEED: Professional Scrum Facilitation Skills Training (PSFS; English; Live Virtual Class)Live Virtual Class €749 incl. 19% VAT
🖥 🇩🇪 July 9-10, 2024Professional Scrum Product Owner Training (PSPO I; German; Live Virtual Class)Live Virtual Class €1.299 incl. 19% VAT
🖥 🇩🇪 August 27-28, 2024Professional Scrum Master Training (PSM I; German; Live Virtual Class)Live Virtual Class €1.189 incl. 19% VAT

See all upcoming classes here.

Professional Scrum Trainer Stefan Wolpers

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.

Tags: agile metrics, Scrum Anti-Patterns, Scrum First Principles