Demystifying Story Points: A Fresh Perspective on Project Estimation

Story points have become a buzzword in our industry. Sometimes teams get so caught up in story points that they forget there are alternatives. Today we're going to talk about where they often fall short and offer a fresh perspective on the subject.

Here's how story pointing works. You break down a huge task into small, Lego-like pieces, estimate how long each piece will take, and add up all the estimates to find out when your creation will be ready.

Science, indeed! But there's a caveat: this only works under the following assumptions:

• you know how to divide up the work
• you know how long each component will take
• the priorities of the product don't change
• knowing when a feature will go live is more important than building the most valuable version of that feature.

This all works if these assumptions come true. You know, like unicorn stories.

In many ways, predicting when you'll finish a major piece of work using only story points is like predicting the weather a year in advance by looking outside.

What if I told you there was another way to predict the future of a project? We’ve tested it at MadAppGang ourselves, and you should definitely pay attention. We've started to predict the project's future as a whole and check in every week. 

This forces the team to re-evaluate the work on a weekly basis and allows for many exciting conversations about timelines, scope, and technical details. Predictions change, and the team doesn't have to make predictions for unpredictable work, such as new technologies.

We are aware that in theory, story points are an iterative process. In practice, most projects using story points evaluate them once and don't change them later. There are even times when the work turns out to be more difficult than expected, but the assessment remains the same. 

As they say, it’s difficult to manage this knowledge, and the main problem is that adding story points makes estimation somehow easy and "playful".

Story points seem logical — who wouldn't want to know exactly how productive a team is? Measuring productivity is like using a thermal imaging camera on a freezing night. Unfortunately, this method has the same problems as above and more:

• you need to accurately predict the cost of the work
• you need to update the cost when the forecast turns out to be wrong
• work cannot be split between sprints, for example, a task belongs to one sprint but takes two or three.

Story points are often an unreliable source of data because estimates are collected when the team knows the least about the work. A more accurate picture comes from daily meetings and retrospectives. Each day is like a prompt from yourself: more information about the task and a more informed estimate of how long it will take.

If you think the best advancement is when a team gets the maximum number of points, it can become an inside game. But we're not in a sports arena here, we're in the world of software development!

Talking about story points adds an extra layer of complexity to communication. It feels like a kind of code language. Instead, let's talk in a language that everyone can understand. If someone wants to discuss a task, let's just talk about it. And if someone wants to learn more, let them come to standups, retrospectives, and sprint demonstrations.

Discussing the effort required to complete a task and assign points helps to highlight the 'easy' tasks. Add knowing which tasks are the most valuable and it's easy to select the ones that maximise value.

And we've also found that scoring isn't necessary for effective task selection. Try selecting tasks without it to shorten meeting times and focus on work that brings the most value to users.

Every process has a price. Are you getting enough value for your efforts? If you gather your entire team in a room every week to come up with arbitrary numbers for tickets that almost never match the actual task times, you might want to think about the purpose of such a meeting.

Too often we've seen companies introduce story points for no apparent benefit, just wasted time and expectations.

We find that story points sometimes get in the way of recognising when work is no longer useful. Once points are assigned to a task, it's hard to take them away and ask, "Could we have done without that?” And such a task rarely comes up for discussion again, even if the system has long since changed.

Our practicing heroes are confident: story points work sometimes, but they can only be one tool. If you find that it isn't your method, don't worry. Try something else! The key is to release software that works, not to score maximum points in an invisible race.