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
Facebook
Share on twitter
Twitter
Share on linkedin
LinkedIn

Leave a Reply

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

Recent Posts

In The Zone with Marcin Zasepa

Welcome to the second in our new series, ‘in the zone’, a collection of conversations with CTO’s within the CTO Zone community. Each week we’ll be discussing the latest trends, insights gained from there experiences, and future predictions for their industry. This week we’d like to welcome Marcin Zasepa, CTO at Homegate AG in Switzerland. Every episode will be approximately 30 minutes

Read More »

In The Zone with Sasha Bilton

Welcome to the first in our new series, ‘in the zone’, a collection of conversations with CTO’s within the CTO Zone community. Each week we’ll be discussing the latest trends, insights gained from there experiences, and future predictions for their industry. This week we’d like to welcome Sasha Bilton. Every episode will be approximately 30 minutes long, and we aim

Read More »

Case Study: DAZN Data Engineering

Find out how 101 Ways helped DAZN improve their existing data warehouse as well as planning and setting the foundations of the new cloud-based data platform. Click here to download the full case study. Get in touch with a member of the 101 Ways team if you would like to discuss ways in which we can help you and your company

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?

London

101 Ways Limited
41 Corsham Street
London
N1 6DR
United Kingdom

Manchester

101 Ways Limited
No.1 Spinningfields
Quay Street
Manchester
M3 3JE
United Kingdom

Amsterdam

101 Ways BV
Weesperstraat 61-105
1018 VN Amsterdam
Netherlands

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.