Go on have a guess…
I know there is a lot of noise about no estimates at the minute and I’ve got to say I agree with the sentiments of Ron Jefferies in the linked blog post, I agree that we should strive to get to a state of flow that allows us to move small pieces of work at pace through a team.
What agile practices allow us to do is to identify work, prioritise, deliver and adjust based on feedback. None of those things in themselves need ‘estimates’ in the sense the #noestimates movement means, at least based on my understanding.
We do however need to be able to decompose work into team sized chunks, is the decision to do that based on an estimate? I think the obvious answer is yes.
We are also required to ensure we as professionals help the business to understand the challenges and set expectations, we can only do this in the language the business speaks and that’s revenue based.
As development teams we might not like it but we have to translate the work we are asked to do into a language that those who control the purse string understand, I can’t see how we do that without estimates.
I think the problem is more related to how an estimate is perceived, the development team have produced this estimate:
an approximate calculation or judgement of the value, number, quantity, or extent of something.
and the business have received this estimate:
a written statement indicating the likely price that will be charged for specified work or repairs.
We have spent a lot of time and effort considering how we get a better handle on requirements using tools like BDD, user stories and closer working with the business to try to better ensure we build the right thing.
I haven’t seen the same level of effort applied to estimation and #noestimates feels to me like we are either giving up or sticking our heads in the sand for those business facing estimates, we risk alienating the business stakeholders by not engaging them in a meaningful way and that would be a massive step backwards.
I coach my teams away from task level estimation but I feel that stories, feature and portfolio sized items need estimation, we just have to find the right balance.
I’ve recently been looking at getting better at estimation in the team and that led me to Bayesian inference which looked interesting until I realised it was real maths and I have to take off my shoes to count to 20, if you are a keen mathematician or statistician I’d be interested to understand if there is any value to be gained for agile estimation.
That investigation then led me onto Fermi estimation, when we estimate with the team we are asking them to perform a Fermi estimate and we can take some of the good practices from science and mathematics into the team, see this for more Fermi tips
So now we have some new (to me at least) tools in our arsenal to help us to estimate how do we learn to use them? I suggest we try some team workshops to estimate some fun things, how many jelly beans fit in a 1 litre bottle? how many pop corn kernels would fill the room? what does the UK weigh? Maybe split the team and compete for the closest answer.
As the team learn that the estimates they make for fun are not that far out they will hopefully gain confidence in estimating the work they need to do, it will hopefully normalise estimation as it is often a cause for tenseness in the team (a sign of larger dysfunction for sure).
My hope is that we can improve estimation from the team but that is only one half of the problem the business need to better understand what development teams mean when they say ‘estimate’ and stop hearing ‘quote’.
professionalism demands we do our jobs of supporting the business in doing the right things and and as ‘uncle Bob’ says in clean code:
The managers and marketers look to us for the information they need to make promises and commitments; and even when they don’t look to us, we should not be shy about telling them what we think.
The project managers look to us to help work out the schedule. We are deeply complicit in the planning of the project and share a great deal of the responsibility for any failures; especially if those failures have to do with bad code!
“But wait!” you say. “If I don’t do what my manager says, I’ll be fired.” Probably not. Most managers want the truth, even when they don’t act like it. Most managers want good code, even when they are obsessing about the schedule. They may defend the schedule and requirements with passion; but that’s their job. It’s your job to defend the code with equal passion.
Robert Martin is of course talking about defending our decision to write good code but I think that professionalism extends to correctly managing the expectations of the business and to do that we need to give them the information they need in a format they can use and to do our best job at it.