But the best part of the whole discussion of story points comes when I talk about release planning using a Product Backlog estimated in story points (or at least that portion of the Product Backlog intended for the next release of software, which I typically call the “Release Backlog”). That when I spring this one on them:
If your estimates are consistently incorrect, you are perfectly predictable.
That’s when you can really hear the churning going on in the heads of my students.
“Perfectly predictable? How can incorrect estimates be predictable?”
Here’s where I usually wait a few seconds to see if I’ve hurt anybody.
Then I explain – first, that estimates are, by definition, wrong. PBIs (Product Backlog items) estimated at 2 story points may take 80 hours or 180 hours. I won’t know until they’re completed. However, if I get good at recognizing 2-story point items (which will happen if I do backlog grooming properly), almost all of them will fall within an upper and lower limit (don’t ask for the statistical proof, please). In other words, after I do enough 2-story point PBIs, a large majority of them will be more than 80 hours, but less than 180 hours. In fact, the more I do, the more likely that range will get smaller (maybe 100-160 hours) and possibly even smaller.
This is, in fact, one of the most powerful aspects of story points – rather than spending lots of time getting unnecessary precision, we can accomplish the same thing by estimating lots of PBIs in terms of story points and spending a lot less time doing it.
