Demystifying Story Points

Problem

Story points are downright difficult and from the outside it appears like strange magic. Everybody does them differently. Non-technical managers don’t understand them. They can be mistakenly correlated with productivity (i.e. more points per sprint is better) or with time (i.e. more points is more time). Most engineers are keen on the process, but many will approach it by correlating it with a time estimate. For example, this will take me 3 days, so it must be a 3 point story. Story points become meaningful only when you break down the correlation with time and use them to compare complexity between different types of work. Without this necessary change, you are likely to miss your sprint goals frequently for it to be a big problem.

Actions taken

To fix this problem we have to reframe our and the teams’ understanding of story points. We have to look at them as a measurement of complexity and never time. Rather than time, we need to assess each story from the perspective of a) complexity b) risk and c) unknowns. Complexity is often how we estimate our work. Naturally more complex work will take more time. We often don’t think a lot about risk and unknowns until much later and that’s usually when we realize our estimate was off. Risk is a measurement of how risky the change we are proposing is. Is it localized to specific areas? or could it cause wide-spread challenges that we have to resolve? Finally, unknowns is a confidence measure of how well you are familiar with the complexity of this solution and the risk it presents.

Often when we are grooming a story we will arrive at a situation where various individuals may have conflicting assessments of the complexity, risk and unknowns. How we deal with this situation is crucial for success. Never split the difference, never average, never default to the most senior member in the discussion. The only way to resolve this is through discussion to understand why various members think something is more complex, or more risky, or we have more knowledge gaps that we realize. After this, we must re-do the breakdown given the new information we learned. In another Plato story I discuss how to re-frame estimates as budgets.The technique around trade-offs shared there comes in very handy in this situation as well.

This approach will not only help you to come up with more precise estimates but will help you dissolve the perception that the team is not productive. A good estimation process is all about demystifying how we assign story points through a repeatable process.

Lessons learned

• Estimates should be relative. Two estimates should always be relative to each other. They are not time estimates that are based on absolute numbers. From a sprint perspective, it will help you to understand how many different types of complex pieces of work you have.
• When the team is discussing story points and disagree, they have to spend more time to understand why they are disagreeing. This only occurs if we have different information, otherwise given identical info we should be aligned on our story points.
• Optimism bias is inherent in each of us. Our wishful thinking always leads us to override the voice of experience. This fault is the cause why time-correlated story points will lead us astray in our estimates.