Over the past few months, various blog posts have popped up talking about estimation, how estimation is unnecessary, how estimation is waste… and that maybe we should stop estimating entirely and just get down to the business of writing software. If our estimates are always wrong, and most of the time they are, why should we even attempt estimating in the first place?

Agilists eschew absolute estimates in favor of relative estimates, and absolute values to estimates made in more abstract units like story points. Story points are measured in non-linear sequences like Fibonacci to further abstract their value from any notion of absolute time. As a result, agile estimates are only relevant in the context of a stable team with a known measured velocity.

Many teams aren’t any better with agile estimating than they are with traditional estimating and I think this is what leads many folks to reject the notion of estimating entirely. If agile estimating doesn’t work any better than traditional, why bother estimating at all? Personally, I’m a big fan of estimating and teach it to all the teams I work with. Estimating can work… but only if you understand why you are doing it.

You see… estimating isn’t about estimating at all. Estimating is about creating a shared understanding of the requirements, and a shared understanding of the solution. When teams have problems estimating, its almost never an estimating problem, it’s a shared understanding problem. If you can get to the bottom of your shared understanding problem, you will fix your estimation problem.

Shared understanding problems can result from any number of organizational dysfunction’s. Some of the most common are on the product side… insufficient business involvement, insufficient understanding of the business problem, and insufficient requirements decomposition tend to result in sprint planning meetings that are too long and not detailed enough.

When there there is too much of the wrong kind of discovery going on during sprint planning… teams will get tired and frustrated and end up committing to the sprint deliverables without sufficient understanding of what they are going to build or how they are going to build it. They’ve estimated and discussed, but they’ve never gone deep into the details. This always results in too much discovery going on during the sprint, too much unanticipated work, and too many missed deliverables.

The other big shared understanding problem comes from technical debt… poor architecture, quality problems, or even just teams that are unfamiliar with the code base, all result in making commitments without a clear understanding of what work actually needs to be done. When you couple a general lack of understanding about the requirements, with a general lack of understanding about the code, it’s no wonder people are frustrated with estimating.

Giving up estimating is basically giving up being able to give the business any idea of what they are going to get or when they are going to get it… even at a high level. My take is that we can’t give up estimating, we need to get better at estimating, but that means that we need to get better at creating shared understanding. It’s my opinion that creating shared understanding is the main reason we estimate.

It’s not so much the number that matters… it’s the shared understanding matters. If we are estimating without creating shared understanding, we are missing out on the value, and the estimates will always be poor. If our estimation process increases the level of shared understanding, our estimates won’t necessarily be right, but they should be consistent… and consistency is all we need especially for establishing a stable velocity.

So… if we want better estimates, or at least more consistent estimates… our goal isn’t better estimating, it’s more shared understanding. The question now becomes… how do we create more shared understanding?

Share on facebook
Share on twitter
Share on linkedin

Leave a Reply

Your email address will not be published. Required fields are marked *

Recent Posts

Six Actionable Nuggets of Advice for Becoming a First-time Technology NED

If the pandemic has taught companies anything it’s that tech is not something that you put off and think about ‘later’. The last year has seen organisations go through huge digital transformations, whether planned or otherwise. And for those that aren’t technology-based companies, getting the right board-level advice can not only be hard to find, but the difference between success

Read More »

Culture, Skills, and Capabilities // How to become a more data-driven organisation

In our whitepaper “How to become a more data-driven organisation”, we wrote about the five steps that an organisation would need to take, which are: Outcomes: Defining goals and metrics to ensure clear and measurable outcomes Analytics: Implementing and sharing the analytics to improve data-driven decision making Innovation: Testing assumptions through hypothesis testing and learning Data Platform: Gaining new insights

Read More »

Data Platform // How to become a more data-driven organisation

This is the fourth article in our series on “How to become a more data-driven organisation”, and we are going to be focusing on Data Platforms. It is at this point that most people start to dive deep into the technical aspects of Data Lakes vs Data Warehouses, but we want to bring us back up a level and ask

Read More »

Search the Blog

Agile Management Made Easy!

All About Agile

By Kelly Waters

“’Agile’ is one of the biggest buzzwords of the last decade. Agile methods often come across as rather more complicated than they really are. This book is an attempt to unravel that complexity. To simplify the concepts. This book breaks the concepts into small bite-sized pieces that are easy to understand and easy to implement and delivers the message in a friendly and conversational style. Allaboutagile.com is one of the most popular blogs about agile on the web. ”

Kelly Waters

Agile 101 is available to purchase. GAME ON!

Agile 101

Emma Hopkinson-Spark

“Whilst there are lots of ways you can vary the game depending on the teams you have and the learning outcomes you want, the basic flow of the game play is common to all.”
Emma Hopkinson-Spark

Why did we make the game?

How to play the game?


101 Ways Limited
145 City Rd
United Kingdom


101 Ways BV
Weesperstraat 61-105
1018 VN Amsterdam

Contact Us

If you would like to get in touch with one of the team at 101 Ways, then please fill out the form below or email us at contact-us@101ways.com.