top of page

What is a Story Point?

I've got to be honest with you; sometimes, I think story points were invented as a joke - a way to troll well-meaning agile teams by bogging them down in interminable sprint planning sessions where developers argue passionately for half an hour over whether a story is a "3" or a "5."


Many of us have probably had that experience with story points. For that reason and others, I tend to steer folks to story-point-less ways of planning and projecting their work.


But if you are going to use story points, let's get on the same page about what story points are and how they're intended to be used.


Absolute Sizing


Absolute sizing uses absolute units of measurement. Pounds. Liters. Years. When it comes to software development, we generally talk in terms of hours and days (probably the most common way to size software development efforts).


Take a look at the following photo of Jupiter and her moons:


Jupiter and her moons
(Ganymede is the big one)

If I asked you to give me an estimate of the diameter of each of those moons, you would be giving me absolute sizes. Ganymede is 5,262.4 km and so on.


The quantifiable units of measurement tip you off, but the main indicator that you're using absolute sizing is that you can "size" an object without comparing it to any of the other objects. I only need one moon to estimate the diameter size in absolute units of measurement; I don't need to see the others to make that call.


So, when we look at a user story and say it'll take X days or Y hours, that's absolute sizing. You aren't comparing it against another story, and you're expressing its size in quantifiable units of measurement.


What we've come to discover, however, is that estimating software development using absolute sizing is very difficult and easy to get wrong.


Relative Sizing to the Rescue


Let's look at that photo, again.


Jupiter and Her Moons
(Ganymede is still the biggest)

What if I asked you to rate those moons on a scale of 1-5 based on their size in the photo?


Well, you'd probably make Ganymede the 5. You'd probably make Europa (the second one from the left... I think) the 1. You'd probably rate the other two as 3 or possibly a 2 and a 3.


That's relative sizing. We're not declaring the size of the object according to objective measurements; we're comparing all the objects together and declaring the big ones, the small ones, and the ones in between.


There's no way I could look at a single moon in isolation and tell you what the size rating should be. I'd always ask, "Compared to what?" In this photo, Europa is a 1. If we had a photo of all the moons of Jupiter or all the moons in the solar system, Europa would probably get a 4 rating, because even though it's the smallest of the moons in this photo, it's actually fairly large compared to all the other moons.


You'll also note that relative sizing is far easier than absolute sizing. It's hard to guess Europa's diameter, but it's very easy to decide if it's bigger than Ganymede or not. What's more, it's a lot easier to get a group of people to agree that Europa is smaller than Ganymede than it would be to get them to agree on a guess of Europa's actual diameter. Most importantly, we're more likely to be right.


When it comes to user stories, story points are a size rating scale. You're basically taking your backlog and saying, "These over here are the biggest. They'll be our 5s. These over here are the tiniest. Those are our 1s. These in between will be our 2s, 3s, and 4s."


Story points do not equate to an absolute unit of measurement. They are simply a rating scale.


What Happens When We Mess This Up


All over the galaxy, I see organizations using story points - designed for relative sizing - as a proxy for absolute measurements.


If your team has a scale like 1 story point = 4 hours or something like that, you've basically eliminated any benefit to using story points. Why not just use hours and days? Why would you invent some weird conversion system?


"I think this story is 3 faloogles."


"What's that mean?"


"Well, a faloogle is 2 days."


"So... it's 6 days?"


"Yes. Right."


"Why didn't you just say that?"


"Because we're agile and we use faloogles."


If you estimate in hours and days, just use hours and days. You gain absolutely nothing by expressing these values as story points. Story points are designed to relatively size items, not absolutely size them.


I realize this seems absurdly straightforward when you see it spelled out, but you'd be amazed at how incredibly common this practice is. In fact, not too long ago, a client shared with me that their developers estimated one of the stories as 0.17 of a story point. That's ludicrous (unless maybe your size rating scale is so fine-grained that 0.17 is an actual point on the scale) and indicates a lack of understanding of how story points are supposed to work.


Even people who should know better get this wrong.


Take, for example, this definition of story points taken from the Scaled Agile Framework's (SAFe) definition of "story:"


Story points are relative, without a connection to any specific unit of measure. The size (effort) of each story is estimated relative to the smallest story, which is assigned a size of ‘one.’ 

That actually sounds pretty solid to me, except maybe for the part of keying all estimates to the size of the smallest story.


But then, this solid theory of story points is torpedoed in practice just a few paragraphs down:


Find a small story that would take about a half-day to code and a half-day to test and validate. Call it a ‘one.’

I won't get into the odd mathematical algorithm you're also supposed to use to factor in vacation days and whatnot. The point is, these people explain that story points have no connection to specific unit of measure and the size is always relative to other stories. They follow this up by demanding that you define your "1" stories as stories that take one day.


Granted, in SAFe's case, they only ask you to do this for the "1"s and relatively size the rest, but the key of our scale is still bound to absolute sizing, and this will assuredly influence the rest of the sizing. If a team is told that 1 story point = 1 day, then how will they size their 2s, 3s, and 5s?


All this illustrates is how widespread and insidious this lack of understanding is.


This has genuine practical problems, of course, because once you tie your story points to a day or a number of days or hours, you have lost all the benefits of relative sizing and are now back into the risks, frustrations, and errors that prompted us to quit doing absolute estimates to begin with.


At that point, you might as well just go back to stating your estimates in days and hours. You know what unit of measurement is consistent across all your teams? An hour. Using story points as a proxy for hours simply gives the appearance of being agile without actually making anything more intuitive or faster.


So, What Then?


Like I said at the beginning, there are plenty of alternatives to story points. You could use a rating system that is explicitly relative. You could count stories completed per sprint. You could use flow-based metrics a la kanban (my personal favorite).


But you can use story points, too. If that's your weapon of choice, though, let's use them effectively for the purpose for which they were designed. Use them as markers of a size rating scale, not a proxy for hours or days.


If you use story points for actual relative sizing, you will find your sizing goes faster and gets quick agreement. If you use story points as a stand-in for days and hours, then you'll have exactly the same issues that you have with estimating in days and hours.


Let's have short planning meetings, shall we?

Comments

bottom of page