# Story Points Reflect Uncertainty

Many teams use story points to estimate the complexity of stories. There are other units, for example T-shirt sizes, that are more beginner-friendly, because they are better at taking the team's minds of estimating time required for tasks. If I have to estimate, I like story points, because they make it easier to help people see uncertainty.

Our product owner likes them, too. For planning it is easy to determine, based on past productivity, that a story point is around 4 hours for one team, and more like 6 hours for another. But this is not a happy spot to be in as a team. How do you explain that a story point in a 21 point story is different than a story point in a 3 point story? That 3 points taking one and a half day is a pretty sure thing, while 21 points taking 10 and a half days is precise, but most likely wrong?

Story points represent uncertainty. More story points mean more uncertainty. How can we make this uncertainty explicit? Well, story points are based on the Fibonacci sequence: 1, 2, 3, 5, 8, 13, 21. A number in this sequence is based on the sum of the two previous numbers. To see the uncertainty, let's say that 5 points is *actually* in between 3 and 8 points. The number before 5 in the sequence is the lower bound, and the following number is the upper bound.

This is similar to how we would express uncertainty when estimating required time: we would estimate a lower and an upper limit and say that the actual result is likely to lie somewhere in between.

When planning a sprint or a release based on story points, *this uncertainty is a risk.* If you convert story points to time, you should assume an interval caused by uncertainty and calculate based on lower and upper bounds.

Once you become aware of uncertainty, you may find that it is totally fine to have a 5-point story in your sprint backlog. But you will question a 13-point story, when you realize that it could take somewhat between 8 and 21 points of time.

Now the solution to handling this uncertainty becomes obvious: slice stories into smaller ones. Fewer story points mean less uncertainty. More smaller stories sum up to something safer. Reduce the risk by developing in smaller increments. That's the agile way.

When we become really good at slicing stories into smaller ones, we will want to do this. It feels much safer. And once we are used to developing only really small stories, what is the point of estimating their size?