Never split the difference in Scrum estimations
Never split the difference is a fascinating book by Chris Voss, nothing to do with software. Voss was once a hostage negotiator for the FBI. The stuff of high-octane Hollywood movies, only for real. He has since switched to the less stressful career of corporate advice and writing said best seller.
Splitting the difference seems a legitimate compromise when the parties can’t agree on their final offer, but in fact everybody gets a bad deal, albeit equally bad. The buyer overpays while the seller is underpaid. The better option would be to walk away. Here’s a mildly amusing footwear example. If you really can’t decide on the black or bron pair, choose the grey pair. Don’t wear one of each. There’s a 50% chance it might rain on our hike. So let’s wear one waterproof boot to be on the safe side.
These are silly examples, but whenever in story point estimations we encounter a big difference of opinion and agree to just split the difference we act no less absurdly. In a sale the parties naturally have conflicting notions of the best price, but in Scrum you are not negotiating a sale, and you should not have a different agenda. An estimation is not an opinion, much less a matter of taste. It should be an informed judgment of the level of effort and (un)certainty involved in doing a unit of work with the entire team. That last phrase is crucial. You are supposed to judge how long it will take the team, not a clone army of yourself. If we can agree on that then a task cannot possibly be worth three and eight points simultaneously. Either one is right, or both are wrong. In this universe the bottle can’t hold 300 and 800 peas at the same time. If you assume the truth lies in the middle, what you are really saying is that you expect both parties to be equally off the mark. You hope Daniel’s over-estimation happens to be equal to Brenda’s under-estimation. That’s a baseless assumption.
When all the team members have enough foreknowledge of the task at hand and a shared understanding of the unit of sizing then individual estimations should not differ widely. The fact that they so very often do may mean two things. Either you have different assumptions, unequal knowledge of the task, or not enough mastery of the domain. Or you could still be unclear about what a unit of estimation really means. It doesn’t hurt to refresh so everyone’s on the same baseline.
By its nature the word estimation carries an element of uncertainty, of guessing. While we cannot fully eliminate uncertainty, we must minimize the number of educated guesses. Make explicit what is based on hard facts and what are merely assumptions. The more uncertainty, the higher the estimation. If after all you still cannot agree on the size of the task because it’s either too complex or not clear enough it is obviously not ready yet. Just as it can sometimes be wisest to walk away from a sale, we shouldn’t force a bogus estimation. Send it back to the drawing board.
Originally published at https://jaspersprengers.nl on January 29, 2021.
