Everyone who has used Scrum knows what user stories are. Most people who have used Scrum know what story points are. Few people who have used Scrum really get the idea behind story points. It’s not too surprising. The concept doesn’t always fit well into the ultra left-brained, concrete mindset of most software developers commonly found in the wild. The problem is that developers over-think story points because they don’t fully understand the context in which they are being used. I’m going to talk a little bit about how story points work and why we need to stop thinking so hard about them.
So what are story points?
I’m glad you asked. To answer that we need to first talk about stories themselves.
So what are stories then?
Another great question. You’re good at this. I’ll answer it by telling you what stories are not — requirements. Stories are not requirements. They are not designed to tell you exactly what the software should do in minute detail. In fact, they’re not really supposed to go into much detail at all. Stories are supposed to act as placeholders for a conversation between the person who really understands the requirements and the people writing the software. That conversation is where the actual requirements are communicated. Scrum is an interactive methodology; it favors dialog over documents. So something like…
“As a user I would like to be able to see my current shopping cart total on the screen at all times”
…is a perfectly good story. You’ll notice though that it doesn’t convey many implementation details. Where on the page does the shopping cart go? What does the icon look like? When does it get updated? All those little details are figured out in a room with all the relevant parties involved in a real time discussion featuring whiteboard art and impassioned speeches.
Okay, fine stories aren’t requirements. Weren’t we supposed to be talking about story points?
Yes, I was just getting to that. Since stories lack the details of real requirements, it doesn’t make sense to try to estimate those using metrics like time. When we are doing story sizing, we don’t know enough about them to estimate at that level. That’s why when you’re doing your backlog grooming sessions and playing planning poker you don’t say things like, “that story will take me two days”. If your story is written properly, you really won’t have enough information to make that call.
Okay, so at some point we have to determine how long the story is going to take. When do we do that?
That happens during sprint planning. You decide which stories you want to execute during the sprint (the top 10 from the backlog for example), and you break those stories up into tasks. So the shopping cart story might be broken up into tasks like:
“Design icon”
“Write database queries”
“Update HTML”
The tasks are the things that we assign time to. So “design icon” might take 2 hours. The key thing to understand here is that until you break the story up into tasks, you haven’t really thought the story through all the way. That’s the point of tasking out a story; it forces you to think about it at a detailed level — a level low enough to perform a reasonable time estimate. Stories alone don’t have this level of detail.
So if I can’t use time to size a story, what can I use?
Well, many people are using a modified Fibonacci sequence to size the stories. These are numbers like 1, 2, 3, 5, 8, 13, 20, 40, etc. These ARE NOT DAYS OR HOURS. These are just numbers used to represent a rough story size. You could use words like “small”, “medium”, “large” and “ginormous” if you wanted.
But I need some sort of frame of reference. How big is big?
Very true. Stories are sized relative to each other. So a “big” story is one that is generally bigger than most of the other stories in your backlog. I like to start out by picking a medium sized story and assigning it a value of 5. A story about twice as large as that would be a 13 and a story roughly half the size would be a 3. The point is that you must resist the urge to convert story points into time in your head. If you start thinking things like “Okay this story will probably take me about a day so that means a 5”, then you’re doing it wrong. Story points are about gut calls. Stop thinking so much.
Thinking so much? Buddy, I get paid to think!
I know, we all have the same urge to reduce this stuff down to concrete things that our OC- riddled brains can quantify and categorize and measure. Fluffy nonsense is for marketing people and hippies. I get it, but in this case you have to understand that we are keeping it fuzzy because at this point, it’s still a fuzzy problem.
There’s only one exception to the rule: when you are dealing with velocity. In case you don’t know, in Scrum, velocity is a measurement of how quickly you are getting things done. One way to do that is to look at past sprints and figure out how many story points, on average, you get done during a sprint. If your team is roughly capable of 50 story points per sprint, then you can use that number to estimate (I and mean in the really rough sense) how quickly you might finish up the stories still remaining in your backlog.
AHA! Story points DO equal time! You just said it! I saw you say it!
You got me. Yes, in some cases story points do translate into time. But only for the purposes of determining a velocity and only after you have a few sprints under your belt. And you never equate them to time when you are doing planning poker. The time component to the story point concept is for high-level schedule estimate only!
It can take a little while to fully grasp the idea behind story points, but once you do, it really helps with more accurate and realistic estimates. And those are two things that software estimation desperately needs.
