You won’t work in the Agile world for too long before you start hearing talk of #NoEstimates, but….
What is this crazy talk?
Should you pay any attention?
Is there anything in it?
So, right off the bat, this sounds extreme, evangalisty and out-there-Agiley doesn’t it? How do we plan and communicate with stakeholders if we don’t estimate? We have been estimating for years so why would intelligent and respected people suggest that we stop doing so now?
- Firstly, #NoEstimates DOES NOT MEAN #NoPlans.
It just means that we need to think about things in a slightly different way and that in some circumstances these other ways can be more helpful, more cost effective, more engaging and more accurate than estimating.
Okay, so that doesn’t sound quite so crazy, does it? But how does it work?
Well let’s start with a question, why do you estimate? The usual answers are:
- Sharing a plan
- Understanding costs
- Being able to make priority calls
- Facilitate problem-solution discussions
These are all good, and I would say, valid reasons. Note thought that the estimates themselves are just a means to an end.
One problem with estimates, however, is that they are often used in other ways too which are less helpful and have negative side effects, such as:
- Creating inflexible, output-focused plans when we know that adaptive, outcome-focused, planning is at the heart of progressive and successful business.
- Measuring how ‘productive’ a team or individual is when we know that value created is no way analogous to stories points completed.
- Encourages the creation of large backlogs of work to generate options which is all kinds of wasteful.
- Encourages or enables us to plan around dependencies across teams which we could be better off addressing rather than masking.
- Creates many meetings discussing relative sizings and options which are not helping us to understand our customer better or to ship product.
So if we take a (big or maybe huge) step back and think about this, can we get the outputs that we desire without the negative consequences?
The #NoEstimates movement think that we can.
The most basic way, ‘Card Counting’ is really just a natural progression from estimation. This just means that we count the number of backlog items or Stories that a team complete and base our estimates of progress on that count. We take it as an assumption that we have a stable team and that our stories will be on average a similar size e.g. some big and some small.
- This is evolution not revolution.
A few years ago Agile teams were all about ‘Ideal Days’ then we started to think about ‘Story Points’ and some teams then started making all their stories roughly the same size to become more predictable. Teams implementing Kanban too also planned in a different way to the Scrum sprint-based model. Scrum and Kanban planning are both metric-driven and based on empiricism though, as is #NoEstimates.
As you have probably seen in the Spotify Engineering videos, Agile teams plan in ranges but this is still fairly primitive and is only based on actual sprint averages. Card Counting too is pretty basic but thankfully statistical geniuses have devised probabilistic methods such as the Monte Carlo method. This further removes the human element from the planning process and provides sharable statistical models that can be communicated and discussed with stakeholders.
I am not going to go in to detail on the Monte Carlo method here, that has been covered elsewhere, but the 20,000 ft view is that it:
- uses real data on story delivery time from your team
- extrapolates your real data set to create a great-big-fat data set using statistical magic
- generates a model that allows you to visualise what the cone of uncertainty actually looks like
- enables better, data-driven, risk-based discussions with stakeholders
This example shows a project forecast distribution graph. On this you can see the probability of a certain number of backlog items being completed in a given number of sprints. Are your estimate based plans this accurate? Are they this easy to produce?
Pretty cool isn’t it? If you would like to learn more, check out this talk from Troy Magennis. Troy dives in to great, simple, evidenced examples to demonstrate the benefits of taking a probabilistic approach to forecasting. He has also has a range of tools available to use under the creative commons licence.
But could this help us to diagnose and treat anti-patters such as dependencies and large or unstable teams and could these methods help is a variety of circumstances?
So Estimates or #NoEstimates?
Well for me, estimates are not evil. They have a place and much of the conversation around estimates for planning and elaboration is still necessary. In those cases, you could try forecasting using Estimates and NoEstimates to see which is more accurate.
That said, I have certainly wasted my fair share of time on producing (too detailed) plans that we had no intention of delivering to enable CEOs to make decisions. I have also sat round the table and had discussions about the Cone of Uncertainty with other CEOs who listened politely but looked on somewhat blankly. For me, any thing that adds some science in to the planning model and saves my colleagues from the wasted hours of planning discussions has to be a good tool in the chest.
That said, I have certainly wasted my fair share of time on producing (too detailed) plans that we had no intention of delivering to enable CEOs to make decisions. I have also sat round the table and had discussions about the Cone of Uncertainty with other CEOs who listened politely but looked on somewhat blankly. For me, any thing that adds some science in to the planning model and saves my colleagues from the wasted hours of planning discussions has to be a good tool in the chest.
So, will this work in every scenario? Can we cancel all our estimation meetings right now???
Well… No. But this is not the point. This is another tool in the chest that helps us work better, smatter and to share better quality information with our colleagues.
If your problem space is highly exploratory or complex then you will have no idea how many backlog items to plan for.
If you don’t have stable teams and goals then there is no place for empirical planning models.
If your backlog is full of large items that will split in to elements of widely varying sizes then this will not work for you either.
But could this help us to diagnose and treat anti-patters such as dependencies and large or unstable teams and could these methods help is a variety of circumstances?
Sure, why not. Run an experiment. Give it a try and see if it works for you. You can use it along side your existing models with no extra overhead and see if it helps too.
Oh, and just for the avoidance of doubt, to the best of my knowledge, none of these words were ever uttered by any current or former POTUS or their spouses but thanks for holding up signs on the internet all the same 🙂
(Visited 89 times, 1 visits today)