To estimate or not to estimate? Is it even a valid question?

The #NoEstimates movement

Previously, I discussed a recipe for a technology teams’ efficiency and inefficiency.

I’ve also participated in a few online opinion exchanges about the value of estimates and estimating activities in digital product development. So, I thought maybe it’s a good idea to address this topic in a little bit more detail and dedicate an entire article to the #NoEstimates idea.

Managers like estimates, because they believe the estimates will help them to better control the progress of projects and digital initiatives. Sounds right and logical but… there’s a well-known antipattern of asking for estimates and then simply checking to see if reality is the same as the estimates.

Estimates are unfortunately too often treated as deadlines. This phenomenon leads to inefficiency, because it’s always better to overestimate than to challenge oneself and possibly underdeliver.

Man-days used to dominate the landscape decades ago, but now we live in the world of story points. Planning pokers and other techniques are there to improve estimation accuracy and iron out any misunderstandings about the actual goals of particular user stories.

There are many people (I believe the majority, but cannot provide any hard data to back it up) that cannot even imagine projects without estimates.

Does this sound too radical? Does it bring chaos and doom to the projects? Let me explain.

#NoEstimates as in “the best effort”

Let me use my own experience to explain this (revolutionary?) idea.

In a truly motivated goals-driven team, especially a compact one (such as Avenga Labs), I often use the best-effort approach of doing the most important things first, as fast as possible, without jeopardizing quality.

We use timeboxing to verify where we are and what we are to do next. This creates a heartbeat, but it’s something much lighter than a Sprint, and with no planning poker, etc.

We decide what we want to achieve by the next checkpoint (usually weekly) without estimating how much time it will take.  Then, we just fit in everything we need to before the next checkpoint.

In the estimation world, it means simply, 1 – the task will be completed, or 0 – the task won’t be completed by the next checkpoint, and not doing any tasks that won’t fit.

No man-days, no story points, and no Scrum. But, what we get instead is the commitment to deliver.

It works very well in experimental Proof Of Concept and research activities, which may or may not last for a few weeks depending upon the results; for instance, in the case of spinning off new research threads or killing those which are not delivering promising results.

There are other flavors of #NoEstimates, but many of the principles remain the same.

Benefits of #NoEstimates

No estimates take the organizational load off from that which is spent on estimating, discussing estimated work items, and documenting estimates.

The best way to achieve results is to… actually do things to achieve them and do activities that create end products (code, demos, documentation), and anything else should be as minimal as possible. LEAN spirit is the key.

We also get rid of the guilt problem. One task might take more time than another and vice versa, but that is OK as long as the intermediate and long-term goals are met. No problem, no discussion, and no explanations are needed at any time.

Do estimates really matter if the goals are met? No, they don’t.

Do they matter if nothing has been done? No, it has happened already and we cannot turn back time, regardless of having estimates or not.

I like this pure spirit of commitment, either someone promises to deliver something or not. . .  yes or no. How she or he divides the work between different activities doesn’t matter in the end as long as the results are delivered.

Another benefit I might add is that very often we do it (use #NoEstimates approach) without even realizing it. We know we need to do something before the date XYZ,  so it’s very natural as well. For instance, I never plan how long it will take me to write a new article, but I know I plan to do it by the end of… given date.

Criticism of #NoEstimates

The first point usually raised by the critics is that #NoEstimates are in the form … of estimations, but reduced to YES or NO (one or zero) for the next iteration.

And… I agree, but this simplification also means a qualitative change, not just using the limited set of possible estimation values. Commitment takes the front seat and the numbers game is not even there.

Another point is that traditional story point discussions are a great opportunity to discuss the different understandings of requirements and the different technical ways to achieve them. I agree, but so are the #NoEstimates.

In many more regular (with all due respect) activities performed by larger teams, there’s a justified need to have a picture of the current state of the project and estimates can help to achieve that.

There are also voices that say that switching to #NoEstimates did not change too much, but they are just suffering a little bit from the management anxiety caused by not having story points, but otherwise, there’s no miracle happening like more motivated and empowered people delivering better results faster.

To estimate or not to estimate?

Sorry, it’s not that simple. Your mileage may and will vary.

In highly skilled and focused teams, we can skip this entire ceremony of estimating and focus on delivering products faster. Get rid of overhead and just move on, committing and delivering on time what was expected, and verifying progress using iterations/sprints/checkpoints.

In a broader picture, the teams often seem to require external triggers from the managers to verify the progress against the estimates and deadlines. Not everyone is a self-starter and has enough internal drive to achieve the best results as fast and as good as possible.

And there’s everything in between, like multiple teams in one larger product organization with different attitudes, drives, and motivations.

The role of the managers and each team member is to pick the best tool for the job in a given context.

Please give #NoEstimates a thought and do not cross it out as a viable option for the future.