Good afternoon!

I had some team members ask me about story points recently and I thought I’d share what we talked about.

We use story points on all our projects for estimation, but I hear a need for a reset on what story points are and how we use them.

So what are story points? Story points rate the complexity of a task, not how many hours it would take to build it.

Why not estimate time? Well, James could build a whole migration path in the time it might take for me to Google that. But I write CSS faster than most backend devs. But all of us can probably agree on whether or not that migration has teeth to it or if its simple. And we can also probably agree on how big a theming effort is. Also, we lose hours to waiting for clients to get back to us, and there’s hours needed to handle tasks like code review or deployments. Would that be included in an estimate of hours?

See it like this: I can’t tell you how much a motorcycle or a pickup or an airplane weighs, but I can tell you that a motorcycle weighs less than an airplane, and a pickup is somewhere in the middle.

Over time, a team’s “velocity,” the number of points they accomplish in a sprint, will hit an average. To build on that example, using that average velocity, as the PO, I could go to the client and ask if they want one airplane or five motorcycles this sprint and let them make a more informed choice.

Is this like using “shirt sizes?” Sure. Your PO or PM likely just translated your story sizes into story points when they were entered into JIRA. Sometimes when estimating a story quickly or in front of clients, it can be more comfortable to use shirt sizes, especially if the client tends to assume that points are just hours. But ultimately, we want everyone using points when possible.

For story points, we use what scrum geeks would call psdeudo-Fibonacci numbers: 1, 3, 5, 8, 13, and 20.

1 point is a “check one box,” “change one label.” Whatever you’re facing, it’s probably not just one point. On the other end of the scale is 20, even 40, and 100; if you feel like you’re facing something that complicated, THAT IS VALID, and it’s a sign to POs and PMs that the story you’re looking at isn’t a single business need, it needs to be broken down.

In the middle, 3, 5, 8, and 13 are the standard sizes we deal with. You’ll notice that these numbers get further apart as they increase, that’s because it is more difficult to estimate with granularity at scale. The difference between a 1 and a 3 might be obvious, but a 13 to a 15 isn’t. So if you’re considering sizing something a “10” because it isn’t an 8, then it really is a 13. The additional points cover the greater uncertainty in the estimate.

What if I sized something a 13 and it was really easy? Then you got lucky. You estimated the business need as complex, but found a shortcut in its technical implementation. You’ll run into plenty of 13s that take you a long time, too. Once you’ve estimated the need, don’t go back and change the estimate. And that’s your litmus test on whether something is a scope change: if the business need changes, the task should be re-estimated. Make sure your PM or PO knows if this happens. Otherwise, the averages over time will start to account for a pattern of over or under estimation. This is why it takes several properly sized sprints to start to get usable velocity data.

And what if that 13 is almost ready on Demo Day, but it can’t be deployed just yet? It doesn’t count toward the velocity of this sprint because the value-add wasn’t ready for the client this sprint. So you’ll have a velocity drop this sprint, but if you wrap it up in ten minutes next sprint, you’ll have a velocity inflation next sprint, which averages out. Don’t sweat it. And pat yourselves on the back always for good, hard work. While it’s important to meet the sprint commitment if you can, don’t just tie your team’s kudos to the sprint’s velocity, at the end of the day it’s just a useful business intelligence number.

To wrap it up, I’ve created a one-pager at storypoints.info that covers these points and offers a guideline of what kinds of tasks represent what sizes. This was informed by the JIRA history of our organization across multiple projects. With this as a starting point, when you estimate, hash it out with your team. This is just a little intro, it’s not a ruler