When answering the question ‘why story points?’, it’s easy to focus on the benefits of story points and relative estimation over other forms of estimation. However it’s important to answer this question in an even more fundamental way. Once we create story point estimates, what can we actually use them for? Are they worth creating at all?
Cost vs Benefit
When prioritising the backlog it can be useful to not only consider the value of the piece of work, but also the cost in terms of development effort. Quick wins, which are items with high value but low effort, may be prioritised against low value items requiring a lot of effort. It’s also possible that if the gap between the value delivered and the cost to complete it is large enough, that the business may choose not to spend the time at all. Remember that the Product Owner is tasked with maximising return on investment. Story points allow the Product Owner to make decisions, ideally without the team having to spend a lot of time on items that may never be implemented.
Story points, when combined with a team’s historical velocity, also give us an indication of when a feature will be delivered. This delivery date is at least based on past performance rather than hopes and dreams, yet it is important to note that it is still only an indication. Estimates are estimates and, when working on complex products, it’s always possible for something to go wrong (or right!). Despite that weakness, story points do at least give us an idea of how we’re tracking as we adjust the estimated delivery date with velocity. As we progress through the work, our estimates get more accurate according to the cone of uncertainty.
By measuring velocity, we get an indication of team productivity. If the team is able to take on more story points, assuming that the stories are relatively estimated, then this suggests that productivity has increased. This metric comes with a major warning however. As soon as teams start focusing on increasing their velocity, or managers start evaluating teams’ on their velocity, the metric will become useless.
You get what you measure because people are smart and every metric can be gamed. When using velocity as a productivity metric, it only gives you a starting point for trying to understand which types of work slow the team down and which help the team deliver more. As soon as you link a drop in velocity to the idea that the team is slacking off and not working hard enough, you will get one of two things. The team will inflate their story point value so that it looks like they’re delivering more. Or worse, given your lack of trust, the team will decide to live up to expectations and stop trying.
Possibly my favourite purpose for creating story points is as a tool for triggering conversations. Asking why an item is estimated twice as large as another can help to uncover underlying assumptions and improve understanding between the team and the Product Owner or customer. Of course there are many other ways to uncover such assumptions and story points shouldn’t be the only tool in your belt for doing so.
Hopefully that gives you some insight into how story points should be used as well as warning you away from the basic pitfalls. I would recommend that if you don’t need estimates for any of the above reasons, then you probably shouldn’t be spending time creating them.