Why Story Points?

In an agile way of working we have gotten used to estimating work using story points. Not everyone finds this useful and many discussions have been had about it. In this blog post I want to give my opinion about story points, their benefits and downsides.

I tend to be in favor of using story points for estimating, why? Because they offer a level of abstraction that you don't have with time. They try to let you focus more on comparing tasks and their estimations. Moreover they take away the pressure of finishing a certain task within the estimated time period. They are a natural self-leveling mechanism where estimations will level themselves out over time and they are robust against changes in your definition of done. If at some point you start documenting things better, add more tests, you don't have to start adding more time, instead you can keep using your same estimating mechanism.

That being said, there is a big flaw that undermines the entire story point estimation mechanism and that is that the precious resource we have is time. Whether your work in iterations or not, at some point you want to know when a certain milestone will be reached. Business will want to know when the application will be ready to go. They don't care about how many story points it will be, they need a date. In comes velocity which measures the amount of story points per iteration, and by doing so links your story points to time. If you have two week iterations and your team of 4 delivers 40 story points, that means on average 10 story points per person per week or 2 story points per man day (assuming a 5 day work week).

So in the end story points are time, and I notice that a lot of developers (including myself) still tend to use time as the initial estimation. In my head it often goes like this: "this ticket will take me 2 days to implement, test, etc.. so that will be about 3 story points."

Having people focus on effort is inherently difficult, since there are multiple factors that contribute to effort. I have had people say you should only look at complexity, but this means that a task that consists of a lot of trivial changes will get a low estimate, even though it takes a lot of time. Effort is more than just technical complexity, the amount of work is also part of it. You can easily see this that when you would split that task in 3 new tickets, you would end up with 3 tickets that have the same estimation as the original ticket, but their sum is of course 3 times as high. This does not make sense as the total amount of effort should still be the same.

So if story points, regardless of how you define them, or how you come up with them, are still just an estimation for time, then why am I still in favor or using story points? A first argument is not so much caused by the story points, but by the values. If you use a (modified) Fibonacci, you are limited in your choices and that is exactly what we want. It is an estimation, it doesn't make sense you estimate something to take 1h 22 minutes. Of course you could do the same using time (with days).

The stress and pressure that comes with a task that says you should be able to finish in 2 days, but is already taking 3 may cause you to quickly wrap it up and care less about quality since you have to meet the target. The same can be true for story points but tends to be less clear/problematic. This is both an advantage and a disadvantage. You should be investigating tickets that take a long time even though they have a low estimate. This doesn't mean the developer is bad, maybe he is blocked and doesn't ask help in time, maybe something unforeseen popped up. The discrepancy between the time spent and the estimate is something to investigate and to learn form. Maybe you have to introduce a new practice as a team or you learn something to keep in mind during your next estimations.

Assuming you use days in a Fibonacci way to estimate, even then it will often cause issues because they directly express the time. This will cause your next iteration to be really packed to the last minute. If you have at team of 4 developers, that means you will need 20 man days of work in the next iteration. Ignoring that this are estimations, you are likely to not hit this target, which causes people to add certain margins of apply a factor to all estimations, which tends to spiral out of control when people take into account that margin or factor as well. Another (and probably) better solution is to only fill the iteration for 80%.

The same can and will happen with story points though if you take the average velocity and assume that that is a number you can always hit. Estimations are always ugly and will never be spot on. A good way to improve your estimations is to not just use a single number, but instead a best, average and worst case. This gives you much more information than just a single number as the single numbers seems to give you a 100% certainty. Estimations talk about probability and they should be used as such.

Another difference with days is that story points don't push people to show off. If I give an estimation on a task of 3 days, but someone else only 1 day, does that make me a bad or slow developer? It takes away the urge to show off to other people that you could finish a certain task faster than anyone else. Story points are independent of the developer and one developer may deliver 2 story points per day, while another may only deliver 1.5 per day and that is perfectly fine. As a matter of fact, it will likely even depend on the task and the experience of the developer, but the task with for all of them be the same amount of story points.

Story points open up the discussion and let you focus on the task and what needs to be done and how it can be done and the challenges that come with it. It takes away opinions of people on how fast you should be able to do something.

So in the end I still prefer to use story points over time-based estimations. An important aspect here is that you actually use these estimations. The concept of velocity was introduced to translate your story points to time and make predictions on how long it will take to finish a certain amount of work (with a certain probability). There are cases however where the deadlines are less strict and it may not even make sense to estimate, which will be the topic of my next blog post.