Story Points that mistook themselves for Hours

drafting instruments on top of table
Photo by Fleur on Unsplash

This article is part of my Agile series, where I discuss various Agile-related practices from developer’s point of view.

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:

Book, Kindle, coint, laptop and a table

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):

  1. It’s way more natural (and easy) to compare things relative to each other, and
  2. 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.

If you liked this article, you might also like:

If you want to stay up to date about what’s happening on this blog, you may befriend me on LinkedIn, follow my posts on Instagram and Twitter, or subscribe to RSS feed.

If you prefer, you may also subscribe to my mailing list:

2 thoughts on “Story Points that mistook themselves for Hours

  1. >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

    I think that one of those two things is much more important than the other. If stakeholders demand a deadline, at some point you will have to convert story points to hours. Maybe not the individual story, maybe the unit will be “number of sprints”, but at some point you will have to translate it into a date. And if you have a wrong “story points” estimates, you will get the same result by missing the deadline. I think the lesson in your example is “humans are bad at estimating, so take advantage of large work packages (30 things) composed of a multitude of similar tasks (similar components), so that by implementing one of them, you get a better idea of how long it will take to complete the whole package”.

    In general though, I thoroughly agree with the article. Thinking in story points rather than hours is a good brain-trick to leverage what we are good at (comparing things) rather than what we are horrible at (giving absolute estimates). It also relieves a little the pressure of measuring and estimating time for every little task, and focus more on getting the “sprint” right (where things hopefully balance out), rather than each individual feature.

    I also love the idea of defining discrete steps for story points. This technique is also applied plenty in frontend design systems where typography/paddings/margin sizes are packaged in discrete steps “tiny, small, medium, large, x-large”, rather then giving the developer the extra cognitive load of thinking every unit (2em? 14px?) for everything.

    I suggest adding a “5” into your beginner “1, 20, 50 and 100” sequence, having the second step 20x bigger than the first one is probably a bit too much of a jump 😀

    As usual, thanks for sharing Mihailo, very informative and useful stuff.

  2. Luca,

    As usual, big THANK YOU to you for spending this much time to actually provide a valuable feedback! Really appreciated man!!

    Let me cover some of the great points that you had:

    >> If stakeholders demand a deadline, at some point you will have to convert story points to hours. Maybe not the individual story, maybe the unit will be “number of sprints”, but at some point you will have to translate it into a date

    Absolutely agreed! Maybe I should have made it a bit more clear really. The idea that I wanted to “share” is — by using story points, you are, at least in my point of view, buying some time to actually learn your complexities, while at the same time communicating back the “backlog estimate”. And, as I mentioned, no matter how much the stakeholders push for deadline, there’s always room for couple of sprints for experimenting. Really.

    But anyway, yep, I don’t know if the wording is correct, but as far as I know – this is what you call “velocity”. So after couple of sprints, you calculate your “velocity” (i.e. how many story points you’re “burning” per sprint) and then you can pretty much convert that to hours. And that’s really what always does happen and that’s ok. What’s NOT OK from my point of view is demanding hours immediately (well, it can be challenging :-D).

    >> Thinking in story points rather than hours is a good brain-trick to leverage what we are good at (comparing things) rather than what we are horrible at (giving absolute estimates). It also relieves a little the pressure of measuring and estimating time for every little task, and focus more on getting the “sprint” right (where things hopefully balance out), rather than each individual feature.

    Exactly!

    >> This technique is also applied plenty in frontend design systems where typography/paddings/margin sizes are packaged in discrete steps “tiny, small, medium, large, x-large”, rather then giving the developer the extra cognitive load of thinking every unit (2em? 14px?) for everything.

    Ha, that never occurred to me, but that’s a perfect example, indeed!

    >> I suggest adding a “5” into your beginner “1, 20, 50 and 100” sequence, having the second step 20x bigger than the first one is probably a bit too much of a jump 😀

    Well honestly I generally advise people to start with fewest number possible, and during the same session break it up. I actually would start with 1, 50 and 100. Group everything and then see how many categories “in between” you need 🙂 Rinse & repeat.

Leave a Reply

Your email address will not be published.

Scroll to top