Story points is a journey that I started about 15 years ago. For teams starting out with agile, many think that you have to use story points as a “sign” of “doing” agile. I’m not so sure that’s the case. I first started with story points years ago, but over the last 5+ years I’ve started to stray away from them. I question the value of this technique and so should you.
Story points are relative values of sizes of work – an estimated value. I like to go back to some old texts like Mike Cohn’s “Agile Estimating and Planning” when understanding what were some of the original ideas behind story points where he talks about a “A user story estimated at ten story points is twice as big, complex or risky as a story estimated at five story points”. This implies that “size” in the estimate includes not just how big it is, but how complex something is and if there’s any / how much risk is associated with it. Now we’re dealing with multiple dimensions in the one value – this overload of meanings can often lead to issues.
The other point that gets me is that story points is an estimate. It’s our best guess at what might happen. When you’re measuring velocity your counting up how big “you thought things were”, not how big things actually were. All the bias and unknowns your team can’t see don’t factor in at all. For me, I’d rather deal with the actuals that describe team capability rather than guesses when making commitments.
There’s also another level of indirection with story points – at the end of the day your customers don’t care about how many points something is. They care about how long it’s going to take and / or how much it will cost. To figure out duration (and ultimately cost), you need to use something else known as velocity – ie how many points the team can get through in a given timebox. If you’ve been around agile teams for a little while, you’ll notice that their velocity is often not constant – you can often get a “saw tooth” chart if you track velocity per sprint. So how do you figure out what the estimated velocity is? Well, often teams take a “3 sprint rolling average” to figure that out. My big concern is that there’s so much indirection going on here that it can be hard to predict accurately using this mechanism.
Where I find story points valuable, is where teams, particularly when they’re just starting out, talk about the work and get an understanding of how big items are and “where the dragons are”. The conversation and understanding is valuable, the estimate becomes fairly meaningless after that. Indeed some teams I’ve worked with who were already using story points, all I cared about is that they wrote a number on the card. To me, that was a signal that they had that valuable conversation.
So what should you do instead? Perhaps just count the number of done stories or work items per timebox. Perhaps you don’t need to use the quasi-standard 2 week sprint boundary either – count items per week or per month. That’s what’s known as throughput or delivery rate. Getting an understanding of throughput and how to use it can be useful, because you get away from the agile abstraction theatre and start talking about things in the same language as your customers. Some time ago, Neil Killick stopped by the Melbourne Kanban Meetup to talk about slicing heuristics – you might want to consider this in lieu of doing story point estimates.
Should you be using story points? If you get some value out of them, then yes go right ahead. But please don’t do it because you think you have to in order to “be agile”. Here’s a safe to fail experiment to try – don’t change anything except look at you throughput count over the last several time periods. If you don’t have that data collect it for the next month or so. Compare that to story points – if you think you can predict through throughput, or lead times for forecasting, then perhaps you don’t need to estimate in points, you can use your actual data!