Background
It’s funny really. For whatever reason, I always assumed that pretty much anybody who uses story points actually knows WHAT they are. And why they are different than hours.
Yet, as in pretty much all of my assumptions that I end up writing about – I was wrong. And not just “wrong” but wrong wrong.
- “Story points are the same as hours”
- “Why use one instead the another?”
- “Why are you bothering at all?” etc.
Let me put this straight — story points are NOT hours! And this article is all about explaining WHYs behind that.
Real-life story
It was September I think. Probably mid-September. That crap time of year when you know that summer is about to be over. Everything’s moving towards yellow. Bye bye green.
I remember it clearly as if it was yesterday. We had around 30 components to estimate. Estimate as in – estimate how long would it take to have them finished.
“Let’s just use story points”, I said. My colleague frowned. “Nah, let’s just use hours. Why bother?”.
Weird, I thought. We’ve been using story points all along and yet, we’re discussing hours again. “But, WHY?”, I exclaimed.
“Man, I just know that each component will take us around 3-4 hours to finish. Why use story points if I know exactly how long will it take?”. Good point, I thought. Good point. Why use story points if we know exactly how long will something take, right? I agreed. It doesn’t make sense.
“Let’s add some buffer and agree on 6 then?”. We agreed on that one.
30 components times 6 hours equals 180 hours. Perfectly calculated and communicated to the stakeholders. The deadline was set (yes, this is INEVITABLE!). The clock started ticking.
Well, if I were to tell you that we finished all of this in ~180 hours, this story would be boring, right? Luckily, it won’t.
What actually happened is that after finishing the FIRST component, we realized we forgot to calculate for some additional stuff that HAD TO be done for every single component. So it took us around 9 hours to finish a single one. And this was true for every next to come! We under-estimated by three hours per component, which gives us total of 90 hours that we didn’t count on! Ouch!
Now, if you’re working in a low-paced environment with a handful of stakeholders, you probably have no problems just adjusting everything (and the deadline). However, if you’re part of a highly paced environment with many stakeholders along the lines, you’re in for a wild ride.
Alternate ending – using story points instead of hours
Let’s just imagine for a second that instead of saying 6 hours per component, we said – 6 points. So, 30 components times 6 equals 180 points. So, what’s the estimate of our work? 180 points.
Now we start working on our components and we realize that each component takes around 9 hours to finish. After a couple of days, we’re pretty sure that each component will take that much time. And now we’re ready to make a final calculation – 6 points seem to take around 9 hours to finish. 30 components times 9 equals 270. Add some buffer and we could have communicated 300 hours to the stakeholders. And we’d meed that deadline easily!
So in this alternate ending, what we really did is that we communicated the COMPLEXITY (in points) of work that needs to be done, and yet we took some time upfront to actually learn how long will it take. Approximately at least. And take my word for it, as much as anyone whines, you can always afford some time upfront to actually figure out the size of your backlog.
Story points are not hours; they are complexities!
Frankly, people seem to have problem with this statement. And, in my personal opinion, the issue comes from the fact that when we say “points” we usually use numbers. And, naturally, when you see an estimate in a number, especially when talking about a programming task, your natural inclination is to append measurement unit.
As in – what’s the estimate of that? “60”. It’s just awkward. “60 points”. Nah, we need something tangible. “60 hours”! Right, that makes sense now. Except not! But before I get you to understand this, I first have to explain WHY use story points in the first place.
Why use Story Points?
Because people suck at estimating stuff. As simple as that. We all pretty much suck at estimating hours, distances, sizes (as every man surely knows), etc. Just think of every instance where you thought something will take 5 minutes and, lo and behold, 6 hours later you’re scratching your head.
Why do we suck? No idea. There are bunch of explanations and, if you’re in for it, go and google it. The point that you must keep in mind is – you suck at estimating stuff. And instead of trying to figure out the WHYs, in this specific scenario, I’d like you to focus on tools that we can use to leverage that. Think of it as quantum physics. We pretty much have no clue what’s happening there but we do have rules and approximations that are good enough to do what we need. So we leave WHY to philosophy and we focus on doing what we can – applied physics.
Now, we do suck at providing precise measurements, but turns out that we’re pretty damn good when it comes to COMPARING things.
Just look at this image:
If I were to ask you what the size of each object on the image is, you’d probably need something like 10-30 secs and you’d come up with some measurements that might be right. Or wrong. Who knows.
And yet, if I were to ask you to group these items into couple of categories, say – small, medium and large, you’d need exactly 3 seconds to do this. Even though each item is rendered in the same size, you’d need no more than couple of seconds to conclude that kindle and notebook are medium, coin is small and laptop is big. And the table with all these items? Well that one should be broken down into smaller components – couple of books (medium), laptop (large), phone (medium) and pencils (small).
If you want to make it more precise, you could use – extra small, small, medium, large, extra large. Pretty much sky is the limit. And you should be free to pick whatever you feel like picking.
So how does this translate into story points, right? Well, pretty easy – take any object that you want and make it a “reference” object. Now compare everything relative to it. So, let’s say that Kindle is “5”. Since notebook is similar in size, that makes it “5” as well. Coin is way smaller, so we make it “1”. Laptop is way bigger so we make it “10”. And the table with bunch of items – well that needs splitting, so we make it infinitely large.
How to use Story Points to estimate tasks?
It’s actually pretty damn simple. You take a list of tasks, you pick one as a “reference” and you compare everything to it. Or you could take the smallest (1 point) and biggest task (100 points) and compare everything relative to that. If there’s something you can’t compare (i.e. you can’t put it into a proper bin) – you mark it as infinity and leave it for later on to be discussed and split if needed.
And this is really effective for two reasons (that I’m aware of):
- It’s way more natural (and easy) to compare things relative to each other, and
- It saves time and frees up cognitive space
What people usually do is use some sort of a planning game, for example a “Planning Poker” (more commonly known as “Scrum Poker”). In a nutshell, the way this works is that every person gets a deck of cards with numbers (e.g. 1, 5, 10, 50, 100, infinity) and product owner starts reading tasks that need to be estimated. Every person picks a card that he thinks that matches the “estimate” of the task and places it, face-down, to the table (so that others can’t see it). Once everybody is done playing their cards, they are opened and we try to see the pattern. If all cards are similar then we clearly have a winner. But if we have big gap between smallest and biggest (e.g. 1 and 50), then we have people discuss and try and agree on the estimate.
Once you are done estimating all tasks, next step is to try and figure out how much you can finish within a sprint (e.g. in 2 weeks). Frankly, you have no clue, especially if you’re just starting, so you just pick randomly. You pick one big, two medium sized and five small tasks. Let’s say that accounts for 90 points. So you work on them and at the end of the week you realized that you either underestimated, over-estimated or, if you are really lucky – you picked the right amount of work that you could finish (rarely possible). Based on what you did (under- or overestimate), for the next sprint you modify the amount of work you take in. And you repeat this until you get it just about right. And there, couple of sprints in and you get to know your velocity (i.e. how much you can finish within a sprint). Now you are ready to pimp up your game and try to map the size of your backlog from points to hours, effectively giving you the roadmap 😉
You don’t need to use numbers!
That’s right. Numbers are used mostly because they are convenient. But you are absolutely free to use any other measurement that works for you really!
For example, in my current company, we used to use t-shirt sizes for estimating huge chunks of work. As in – S, M, L and XL.
I’ve also seen people use animals – ant, dog, horse, rhino, etc.
Story points are measure of complexity and it’s really up to you how you want to write them down. It’s just that it’s a bit more convenient to say that you’re burning down 30 points instead of 15 ants, 5 dogs, 2 horses and 1 rhino. But really, at the end of the day, it’s up to you.
Don’t go too crazy
It’s usually recommended to use Fibonacci-like sequence. And people seem to take this literally and use 1, 2, 3, 5, 8, 13, 21, 34, 55, 89, etc.
Uncle Bob in his Clean Agile book has the perfect advice here. What he says is – “what you want to do with these numbers is to get rid of most of them”.
Make it simple. 1, 20, 50 and 100 are perfect for the beginning. Estimate your tasks with these and then break it down further if needed. But again – don’t go too wild or you’ll overload (and hate) yourself!
Conclusion
It’s a matter of fact – we all suck at estimating things in hours, inches, centimetres, etc. And yet, we are pretty good when it comes to comparing things relative to each other. Story points leverage this idea by giving you a framework of categorizing things. Measuring complexities, as we like to say. And if you need a final thought on why the story points are not the same as hours, let me put it this way – because.
Original Source
This article was, originally, published on my blog as part of the "Agile" series. Other articles that might be of interest are - "Oh no, daily again!" and "The Product Owner's Curse".
Top comments (0)