“Why I stopped estimations”

Benjamin Danel, Product Ops and consultant at Thiga, reflects in this op-ed on the purpose of estimations, eventually arriving at the radical conclusion that they are useless.

"It's better to have an estimate that is approximately right than precisely wrong". This sentence, once confided to me by an Agile coach, has long resonated with me, to the point of questioning the very purpose of estimations... And finally abandoning them! How did I reach this radical conclusion?

If I had read this op-ed with this viewpoint at the end of the 2010s, I would have seriously doubted the seriousness of the author... At that time, everyone was immersed in project culture and I was no exception. Equipped with a comprehensive specification, it seemed natural to quickly move into an estimation phase to agree on a commitment around a budget and delivery date. The success of the project greatly depended on the quality of these estimations. Result? Between the requests for changes to the original scope and overly optimistic estimations, heated discussions were frequent when explaining budgetary and time overruns.

With the pace of digital transformations and the rise of tech, Agility gradually took root in France. Man-days gave way to story points, Excel was replaced by Jira, and project managers turned into Product Owners or Scrum Masters, bringing with them their taste for steering, which took the form of "burndown charts" proudly displayed in the open space. A revolution! If you're over 35, I bet you know what I'm talking about... The "Command & Control" managerial culture still struggles to make way for the "Trust & Inspire" required by an Agile and Product culture. Instead of serving as a projection aid, estimations are then used as a tool to measure, or even track - and sometimes compare - the productivity of teams. Unfortunately, this reality is still experienced by far too many teams today.

With Product culture, a good team is judged by the value of its product, and having reliable estimates of user stories (US) does not make it more efficient. Also, the time spent on this utopian search for precise future prediction scatters our energy. I admit, the journey to this inescapable conclusion took me a few years. Five empirically observed elements have reinforced my conviction about the uselessness of estimations. Here they are:

Developments that make the delivery date unpredictable

Yes, estimations help in project management by allowing for a projection on a delivery date for a scope. But in a Product environment, this scope evolves regularly, continuously fed with feedback and new opportunities that bring even more value to the product. Hence, having a reliable projection is just a utopia and brings little interest. In the past, I worked on a revamping project at Axa IM where developers discovered new issues every week. Even considering the probable evolution of the scope in my projection models, it was hard to have a strong confidence index. It's a bit like predicting the weather 15 days in advance in spring (unless you're in Normandy or Brittany). The only solution to have a stable projection would then have been to freeze the backlog, but is that really feasible in Product mode? I’m not even talking here about the management of anomalies and the eternal debate about whether to estimate them. Some teams consider, just like a US, that it's an element to develop and therefore deserve to be taken into account. Others, very majority, think the opposite, indirectly resulting in further deteriorating the reliability of projections.

Almost similar estimations that bring little

With experience, I realized that I always had the same way of breaking down my US. When we estimated the US with my team, 80% of them had a scoring of 5 story points, the rest being spread between 2, 3, and 8 story points. Assuming that all US had an estimation of 5 could almost take me to the same sprint backlog and the same velocity.

The productivity can vary

Team members (developers, QA, etc.) are not machines. For a variety of reasons, they can all have moments that are more productive than others. While the group effect partially mitigates these individual variations, it's impossible to predict the overall productivity of a team exactly, especially if it requires the intervention of several people. I'm talking about team members, and I certainly include the Product Manager. Their weeks are never the same. Sometimes predominantly discovery, sometimes delivery, their availability impacts the team’s productivity, whether it's to validate US or to provide more details on the expected implementation of a feature.

A misusage made to compare and measure a team's productivity

I remember arriving as a PO with a new team that had just been built. At the end of the first sprint review, the Head of Product wonders why the team only achieved 15 points, while the others average 25. Do we have the same reference frame? Can we compare a mature team and a new team? Do we have the same profiles? Without explanation, figures can be made to say almost anything, thus sending the wrong signals. As Vasco Duarte, an Agile coach who popularized the #NoEstimates movement, says: "human teams are not bound by arithmetic. It's not possible to add, subtract, multiply, or divide people." Having a very analytical view of productivity is a problem exacerbated by estimations and velocity.

Little interest compared to the time and energy spent

I can't count the number of hours spent in my career discussing estimations. Yes, it's important that everyone has a vision of the sprint backlog and that it's possible to anticipate certain implementation difficulties, but the time spent quibbling over estimations is too great for what they offer.

Estimations are the "security blanket" for managers with their reassuring aspect. They provide a sense of control.

These observations, I'm not the only one making them. Since the mid-2010s, the #NoEstimates movement has been advocating for a world without estimations. Growing strong in France a few years later, I was convinced that this movement would have gained more ground. Vasco Duarte says that "when the feeling of control and certainty is more important to us than the knowledge of truth, and when the fear of change prevents us from seeking to do better, it's time to question ourselves and face our fears." Yet, it seems to me that teams still apply what has always been taught to them today, without taking the necessary step back to challenge the true necessity of estimations. Jean-Pierre Lambert, an Agile coach, goes further regarding the projection needs that estimations ultimately serve by pointing out the all too frequent cases "where dates are requested for the wrong reasons: because it's the only way a project manager, a manager, or an organization knows how to pilot a project or a team."

But does it mean we must stop everything? The world is not so black and white... The goal of a Product team is to provide a product delivering maximum value to users, while of course being viable for the company, as recently reminded by Valentin Ménard in his op-ed. Estimations can play a role in this equation, but it’s only a secondary role and they must be used wisely. First of all, to negotiate an associated budget, it’s usually required to have a macro-estimation of the total cost of the investment to be made for the product in order to decide the size of the budget envelope allocated. Estimating is necessary, but it must be done with 2 conditions:

• Focus on higher granularity, such as the Epic.
• Agree that the estimation cannot be checked down to the penny 6 months later... Unless agreeing to a scope restriction. Preferring an estimation in T-shirt size then making an estimation of the workload according to sizes and not epics (ex: 1 Epic Medium = 2 sprints) has, from my experience, a better ROI and helps resist the temptation of micromanagement.

At this point in the op-ed, you might be wondering how teams that do not estimate manage their risk of slippage and what data do they monitor? Good news: Kanban and Shape Up methods each give a different and complementary answer, one based on the output (Kanban) and the other on the outcome (Shape Up).

Kanban, inspired by Lean Management, is focused on the productivity of the system rather than the value delivered. Kanban primarily monitors the fluidity of the value chain. Any item started must be completed as quickly as possible, that's what matters most. This time is called "Lead Time" and requires no effort of estimation. As for Shape Up, it focuses on the production of value. A reassessment is made every 6 weeks to decide whether to continue investing in a topic or to stop. This decision is based on the value delivered, not on productivity indicators.

You would have understood that achieving a world without US estimations is not an easy feat and largely depends on the company culture. My experiments with "no estimates" at the US level have always been in contexts where a real relationship of trust existed with my manager. Instead of asking how many points the team has or will accomplish in a sprint, good managers are more interested in the functional aspects of the sprint backlog and do not blame but inquire when the expected results at the end of a sprint are not met. Nowadays, a good Product Leader must be above all at the service of the organization by providing vision and strategy to the teams, with the operations being delegated to the teams that must in turn be able to share their issues and concerns very transparently so he can help them overcome these obstacles. This cannot be done with simple indicators on a dashboard.

In summary, estimates must be taken for what they are, thus used as an aid rather than a precise truth. The role of a PM is to guide their team towards success, not to control their productivity. Pondering over these reflections allowed me to realize that this attachment to estimates is a symptom that sheds light on a manager's positioning. They are the "security blanket" for managers with their reassuring side and give a sensation of control. I am in complete agreement with John Cutler, a successful author on Product, for whom the most important is to "cultivate trust and alignment on decisions and the goals to be achieved".