No Estimations — Stop the Theater
I like to say that I may have invented story points, and if I did, I’m sorry now.
Ron Jeffries
“No Estimations” — our team follows principles of excellence and does not use estimations. We recently had a “book club” and talked about the benefits of not estimating. Attempts to play devil’s advocate didn’t turn out well.
Some teams estimate in story points, t-shirt sizes and time.
It’s difficult to predict, especially the future.
Niels Bohr, Yogi Berra, …
The usual argument for estimating is that “customers want to know when a certain feature is delivered”. We all know that estimating it is a bit of a lie. We can lie now about the delivery date and give the bad news later, or be honest about the state, e.g. “it’s planned for Q1”. And yes, maybe surprising, but satisfies customers a lot of times. They want to be heard and know you’re on it.
Estimates can serve us in a specific case, where we have a legal deadline and by estimating we realize we have too much work to do, and we must pick the most important work items. “No Estimations” is not a religion.
As estimates are guesses, you can think of the following allegory — when you’re a tourist in Paris and you get lost, would it help you to have a map of London?
Estimates are a big waste of time and effort. They are wrong anyway (by definition and empirically) and we will redo this exercise over and over to “completion” of a project. Moreover, everything is based on it, as if it’s the public API of the team, and ETAs turn into commitments and promises, as other teams and departments build on top of them. Dependencies and delays will occur. Better stick to the roadmap in the format of “now/next/later” — now is the current quarter, next is the next 1–2 quarters, and later is beyond. And the roadmap is the order of problems we work on, not features with dates.
“But we do Scrum by the book, so we must estimate!”
Surprise surprise — the Scrum guide doesn’t mention estimating at all. It does mention planning, i.e. the goal to be achieved in the iteration.
“But what if my VP/CTO/CEO feels safer and in control with VUCA (volatility, uncertainty, complexity, and ambiguity)?”
As mentioned before, this is a false sense of security, and is wrong. As Kent Beck jokes “for every estimation, double the amount and jump to the next unit — a 2 day estimation will turn into 4 weeks”. We would be misleading them.
“What if my VP wants consistent iterations?”
The first question is why consistency is more important than working on the highest priority items. Second, we can try to achieve it by breaking stories into small units, so they more or less take the same capacity.
“But the PM has prepared all epics and tickets for the project and we estimated them to 100 story points. Now she knows how big the project is!”
The problem here is two assumptions that are false: first, nothing will change along the way, and second, that we have all the required knowledge at the earliest point in time. We will learn more as we go, and if we bring value to customers incrementally, we will get valuable feedback and increase success. How agile is it to know in advance exactly what you’re going to do, how you would do it and how “long” it would take?
Cargo culting is the phenomenon of having rituals without understanding their purpose and meaning. When having an output mindset, i.e. releasing features by dates, rather than an outcome mindset, which is how to change our customers' behavior, we’re only driven by the predefined features, regardless of their success. We can “play” a Scrum game of sprints and estimations, but in the end it is already determined exactly what is to be done, by someone internally in the company. So it’s not only the overhead of the estimations, it’s about them being redundant. But it does give the feeling of “doing agile” (as opposed to being agile) and doing it right.
One team notoriously experimented with “No Estimations” — they used random estimations, and no one noticed.
You can secretly try random estimates alongside the official ones and retrospectively see which one is closer to reality.
Estimations suffer from peer pressure. An anecdote that happened to me, and repeats often: a senior peer presented an initiative and asked for time estimations. I went first with 16 weeks. He started laughing, publicly shaming me for not understanding the topic, which was clearly very easy (it was our first migration from on-premise to the cloud). Naturally, the peers that followed me estimated 2–3 weeks of work. In reality, it took 32 weeks.
Many have worked in places where the estimations were changed by management request “your estimates are too long for the customer, make them shorter”. Which shows again how pointless they are. Same for the stricter one “but the customer will only pay for half of it”. Someone else committed in the name of the team.
In so many places, story points are translated to time “even though we shouldn’t do it, but it’s like this, right?” The idea of relative estimations fades away. Sometimes to the resolution of 15 minute intervals.
Funnily, many career ladders include “accurate estimations” as a criterion for senior levels. We already know it’s lying to ourselves and our stakeholders.
“No Estimations” doesn’t mean not having a plan. We know how we start, e.g walking skeleton, or the highest risk and next steps. Spikes and Proof of Concepts are also helpful to know which path to take first.
The Pareto principle (a.k.a 80/20) also helps to know when to stop and not slide into diminishing returns.
Having a detailed plan doesn’t really work as the future keeps changing quickly — technology changes, requirements changes, market changes, personnel changes, strategy changes. Governments plan 5 years ahead and we all know how this looks in the end.
It seems like I am finger-pointing management for asking senseless estimations, but sometimes it’s our team members who want them, even when management does not.
Whether it’s the myth that this is the right way (also believing there is no alternative to pull requests), deep habits that are hard to break free from, it comes to the very same conclusions above.
In case they want to know how much to plan for the next sprint — either have a similar amount of tickets, or consider changing from Scrum. Why is it so important to plan which stories go in (again, the idea of Scrum is the sprint goal, not precise tickets to work on), if you always work on the highest priority work items?
How to transition into No Estimations?
Is it really possible to transition into “No Estimations”? Yes!
First, disillusion yourself from the cargo cult of estimates!
Second, realize that for the colleagues and management, the challenge is how to debunk without alienating or patronizing.
Third, without buy-in from the management, it will not work.
Prove to them time and time again that you’re working on the most important things according to the strategy, so they see they can trust the judgment, discovery and delivery of the team. This requires roadmaps not to reflect a feature factory, but rather an empowered team that plans what to work on now, next and later.
For your colleagues, try to follow the logical path by asking:
- what problem are you trying to solve?
- is it the only way?
- can we experiment with something else for a month/quarter?
- if we manage to have all user stories small, and could be estimated all as a 3, failing by a margin of error which would undo itself, would it be close enough to the “regular” error of estimating, rendering them redundant?
This article was written by our team and also posted on Newstore Tech Blog
