Ken Schwaber discusses the development team making a commitment and questions whether maybe we should rename this “forecast”.
He begins with
However, many Scrum Teams use the word commit as if it were a “guarantee.” This is a residue of waterfall
Well, I disagree this is a residue of waterfall. It’s simply a mistake. It reminds me of a Three Stooges routine,
Moe: only fools are positive
Larry: are you sure?
Moe: I’m positive
People are not stooges, but Waterfall or no, most of us just don’t naturally think statistically, it takes training. Moreover, we tend to be overconfident in our estimates. When more than a couple factors are involved, math models usually outperform even experts. Ken goes on,
I wonder if we should change the word from “commit” to “forecast?” That might elicit the impression of the weather forecaster attempting to provide us with the best possible information. She works with what is known and the science of meteorology. She doesn’t provide a guarantee, but something that we can work with to make decisions. We find forecasts used by sales organizations as well.
The meteorologist analogy is apropos. When the weatherman says there is a 70% chance of rain, it rains 70% of the time. People joke about the unpredictability of the weather and how bad the meteorologist are, but in fact they are exemplars of statistical prediction. This comes in no small part from the frequent feedback they receive by examining the data, making a forecast, then reviewing the plan and actual. It is a learning process driven by objective data based feedback.
An equivalent in making a commit to features or a schedule would be “80% chance of all features in by the ship date”. In practice, few do this, and when they do they use 80% in a metaphorical sense to mean “we are pretty confident”. To provide a real forecast will require historical data, feedback, and repeatable methods. This can be done, I’ve seen it done.
One thing Watts taught me was that the project sponsors should ask the developers to “Prove you can do this” rather than “Prove you cannot meet my goals”. The flip side is the software developer’s creed/
When you make a commitment, be honest about your confidence. What are the assumptions? What is the history in similar projects? Do you have enough data to make a forecast, or is this a “thumb suck”. If you can back it up with a forecast like that of a meteorologist, you will you will be head of the class.