When story points were created, they quickly reached the hype peak (where they stood for too long, by the way). However, in the last years, they’ve entered the steep descending part of the hype curve. They have just begun their descending, but I’ve seen people already say that they are useless. So, after all, how and when should I use them?

Let me start saying that I’m not a hater. But I’m the devil’s advocate that likes to bring some discomfort into the room. I just believe that sometimes we stay in our comfort zone thinking that everything is working fine when it isn’t.

A little history

Story points were developed because human beings lack abilities to forecast the future. Our bosses were saying “ok, ok… you wanna use this ‘agile’ thing, but I still wanna know at least when you are gonna finish this new feature!”, and we had to improve our forecasting beyond the “well it will be ready when it gets done” phrase.

Then, we realized that we were actually good at checking whether something was the same size, bigger or smaller than another thing. With that in mind, we created one of the hardest concepts to explain to anyone new to agile: story points.

Comparison or forecasting?

Now we have a comparison tool that does not intend to forecast deadline. Right? Right. It wasn’t supposed to have a one-to-one relationship with time, right? Right. So how does that help to foretell when we will finish a project?

Ok, so you’ll tell me that you use velocity, which is a sum of the comparison values of all the stories you’ve finished in a sprint (which already seems kind of odd). But now, tell me, how many times do you actually finish the entire backlog for a sprint in a sustainable manner (which means QA people not getting stressed and pressured, developers not building tons of technical debt and POs not accepting anything just because they don’t have time)? I’d say none or few. So, why is that?

Well, for starters, we are able, as aforementioned, to see if something is larger, smaller or equal to other things (not so sure about the equal part, but let’s continue). However, we are not good at saying how bigger/smaller it is. Is it double the size/complexity? Is it triple? Who knows?!

Another thing is that if you compare stories with the same points, you’ll see that they will take different times to be completed. And they should because, again, it is a comparison value, not a time-related one.

Based on the last two paragraphs we can deduce that:

1. A 1-point story will probably not take half the time a 2-point story takes. So how do we say our velocity is 3, if these two sets will not take the same time to be completed: {1,1,1} {1,2}?
2. If we can’t even say that two 1-point stories will take the same time, how can we say our velocity is 3, even if we use the same sets: {1,1,1}, {1,1,1}?

Likewise, it is difficult to compare sprint velocities of a team, another common mistake is to compare velocities between teams, or even have a metric for how many points a person can do in a sprint!

We are just creating a false sense of control over our demands and, instead of helping the team, it might actually harm it.

What now?

Ok, Mr. Know-It-All, so when should I use them? Well, they were invented for comparisons! So, use them to compare! Points are not the only tool you have to compare stories. You might also use t-shirt sizes, which are a little bit easier to define than points. In this blog post about complexity and uncertainty analysis, we show a chart that could easily use t-shirt sizes or points in its axis!

Besides that, the moment developers talk and compare stories is great for spreading knowledge among peers and aligning the whole team technically. Another meeting that does basically the same is what we call Task Breakdown, in which some developers get together and try to break a story into technical tasks. But exactly how to do it is a subject for another blog post.

But what about forecasting! How can I answer my boss’ question? We use throughput and lead time, with some statistics behind our answers… They work like a charm and, besides that, they also give us powerful tools to improve our process as well! We have a ton of posts on those topics if you are interested. Here are some of them:

* Throughput and Burnup charts

* Lead Time

* Don’t use average to forecast deadlines

* Use Monte Carlo!

* 12 mistakes you should avoid when using these metrics

Conclusion

The story points concept is useful. Comparing stories is needed, however using that concept to forecast delivery rate and deadlines is not the best option. So, open your spreadsheet, add your metrics to it and let’s start a sustainable development!

What do you think? Do story points work for you? Leave your comments below!