Metaphor for How We Do
Imagine your at a school carnival and you come across one of those big jars full of jellybeans where you are supposed to guess the number of jellybeans.
The closest guess wins a prize, unlike on twitter.
There are scientific strategies you can use to try and predict the number of jellybeans in the jar. Count a row around the circumference, count the diameter and height, then do some math.
Other estimating strategies exist that you could apply to increase the probability of predicting the number of jellybeans.
With careful counting and appropriate strategies, you can probably get pretty close to the actual count.
What if I gave you 15 or 20 small and similarly sized containers and allowed you to fill each one from the jar until it was empty.
Then I let you count the number of jellybeans in two or three of the containers before you make your guess.
Would you go for that? Would that give you a better chance of guessing the total number of jellybeans?
At my current job we use a system closer to the second one to plan our software projects.
We plan two or three months of work by breaking the work down into similarly sized chunks.
If we're at the very beginning of the project, at the front edge of the cone of uncertainty, we have to guess about how much we think we can complete in a couple of weeks.
After we have been working on it for a while, and we feel the chunks of work are similar enough to the chunks of work we've been doing, we can measure how much we've been doing and project out from there.
In either case, we revisit the plan regularly and adjust it according to the data.
Some folks might call what we do #NoEstimates because we don't try to predict how long each chunk of work takes. We don't try to put numbers of any sort on each chunk of work.
We do try to measure and calculate total project length, and we get it wrong.
What we have come to believe is we get it less wrong than when we tried to predict the length of each chunk and add them up to predict the total project length.
From my novice understanding, this is very similar to #NoEstimates.
I'm not terribly concerned with what it's called, but I wanted to share because I think it's close enough to #NoEstimates to help others understand that it still involves planning and risk aversion.
My experience with the estimates-noestimates war is it's less about whether it's a safe and valid way to build software and more about whether what we do is still estimating or not.
As always, I could be terribly terribly wrong.