I warn many of my students at the beginning of CSM classes that some of what they hear during the class may some counter-intuitive. I’m concerned that there are “truths” they’ve “grown up” believing and practicing in the development of software applications that may lead to trouble during the class.
For example, when I talk about a DONEness definition, everyone’s on board. Then, when I mention how long that definition can realistically get (60+ items), people start to pull back. “That’s going to take a lot of time,” they say. “Yes,” I respond, “but they can do it when they build it, or do it more expensively when it breaks at a customer site.”
Most of the disbelief occurs when I talk about story points. I can see my students thinking, “How can estimating items relative to one another be of any use at all?” I spend a good portion of an afternoon explaining how story points work and how to make them easy to use. We talk about “Planning Poker” (thanks Jim Grenning!). We talk about estimating complexity, instead of solutions, and how the Law of Large Numbers makes complexity and solutions directly proportionate.
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.
Now, let’s look at the Scrum team that commits to ten 2-story point PBIs. If they finish them all, they’ll have achieved a velocity of 20 story points that Sprint. Next Sprint, they’ll probably try 20 story points again. The Sprint after that may be a little more or a little less depending on what happens during the Sprint. This continues from Sprint to Sprint, with the team averaging a velocity that will likely be somewhere around 18 to 22.
So, if our Scrum team is getting the same rough number of story points successfully done each Sprint, their efforts to be consistently incorrect in their estimation has made them almost perfectly predictable (that is, we can plan our release at approximately 20 story points per Sprint).
Can you do the same thing with hours? Yes, but it’ll cost you a whole lot more money to do it right. What do YOU want to pay for – completed, working software or very accurate estimates?
To me, the answer is clear.