Story Pointing in Agile: Five Common Myths

JJ Sutherland, CEO of Scrum Inc., shares how development teams can get agile story points right.

People are notoriously bad at estimating things. Whether it’s the number of jelly beans in a jar or, more commonly, how much time it will take to complete a given task or project, one of the characteristics that probably unites us all as humankind is our collective inability to make accurate guesses.

Fortunately, there are a lot of smart people, like Scrum expert JJ Sutherland, CEO of scruminc., who’ve been studying how to estimate projects effectively for decades. In a recent conversation with him, he broke down five common myths and beliefs that may make developers feel reluctant to adopt estimation as a regular practice, such as:

1. All estimates are wrong, so there’s no point in doing estimation work
2. Story points should reflect the number of hours it takes to complete a task
3. You have to be a dedicated scrum master to run estimation exercises
4. New team members shouldn’t be involved in project estimations
5. Always default to the most experienced person’s estimate

“You have to have some kind of answer to the question, when will this be done?” says JJ. Over time, he says that project estimation gives development teams a better understanding moving forward of how much work they can take on.

There’s no denying it though, there are no magic tricks when it comes to estimation. But the more you do it, the better and more efficient you get at it.

Here’s a guide on how to navigate through common myths around project estimation with your team.

Myth 1: All story point estimates are wrong, so there’s no point in estimating

Understanding how much capacity the team has while avoiding burning out in the process is the key to delivering a project on time. So JJ advises looking at estimates as more of a communication tool than a barrier to project delivery.

“Without estimates, all tasks look exactly the same. There’s no way to show your team or leadership that one thing is harder to do than another thing,” he says.

So, not only is estimation a great tool for measuring and protecting your team’s capacity, it’s also a great way to gauge and manage stakeholder expectations.

Another reason estimation work is necessary ahead of a sprint is that it forces prioritization, “because there is a limit to what a team can produce in a sprint,” says JJ.

Estimation work is fundamentally an exercise that helps prevent teams from setting themselves up to overpromise and under deliver. So, is estimation worth doing? Absolutely.

Myth 2: Story points should translate back to hours spent on a task

Story or reference points are typically used during the agile development/scrum process to gauge roughly how long a task will take. JJ notes that you’re likely to have a mix of tasks that look too big or too small, but ideally overall they’ll average out time-wise.

But story or reference points themselves shouldn’t actually be based on units of time. That’s where most estimation exercises tend to go wrong.

Instead, you want to assign a task a relative value based on size. So, for example, as a team you might assign a blog post a value of five story or reference points, but an e-book might have a value of ten because it’s more complex.

Story or reference points can show you more objectively how much or how many tasks, and of what relative size and complexity, that you can fit into one sprint.

Not only that, but using time-based estimates as a metric for team success actually has a tendency to de-motivate people, especially if new challenges crop up that could extend timelines. JJ says it’s better to focus on your progress, not making up hours.

Another reason why you want to work with story points based on value rather than time, JJ says, is because, “part of the idea of scrum is that you’re supposed to get faster. When you work with story points, you can better calculate velocity — the metric that shows how much faster the team is improving over time.”

Teams can typically establish their baseline velocity over an average of just three sprints.

Myth 3: Only dedicated scrum masters can lead agile estimating efforts

“The scrum master is an accountability measure, it’s not a job title,” says JJ. He also describes himself as a “radical pragmatist.” When it comes to how you choose a scrum master, JJ thinks that you and your team should do whatever works for you.

You can assign one person to be the scrum master if they’re particularly invested in the role, or you can rotate the task between team members every sprint. Preferably this person is someone who can be on time and is able to stay organized.

There are some characteristics that make some people better suited towards leading scrums and sprints than others. What makes a good scrum master? “You want someone who takes joy in team success, who enjoys getting things out of people’s way, and isn’t hung up on being an individual contributor. That may not be for everyone, and that’s OK,” JJ adds.

The Scrum Master’s role is ultimately someone who is accountable for facilitating events and story points, removing impediments, and holding the team to continuous improvement. Ideally it’s someone who’s willing to advocate for the whole team and protect their capacity.

Myth 4: New team members shouldn’t be involved in scrum estimation work

This is a common belief among growing teams or teams that have recently been reorganized. And JJ doesn’t sugarcoat the fact that adding new team members mid-sprint can be tricky, but he also doesn’t necessarily think that it has to be a set back.

Remember that your overall velocity increases when the team adds more capacity (a.k.a. More people), so even though you may experience a slight slow down as team members ramp up, the net effect is that you’re likely to get more done in future sprints.

Considering all this, it’s important to factor in how long new team members might need to get into the swing of things, so that means it’s definitely important to include them in estimation work since they’ll also be contributing to the work and potentially at a different pace.

“Estimation ought to be a collective effort. When you have so many different background experiences at the table, you’ll want to hear from everybody so that you’re within the most accurate range of estimation possible,” says JJ.

Myth 5: Always go with the most experienced team member’s estimate

Groupthink is a natural risk during teamwork. For many reasons, such as social pressure, people may have a tendency to agree with the majority or who they perceive as the person with the most power or popularity. JJ says that this is a phenomenon known as “anchoring.” But that tends to lead to inflated egos rather than accurate estimates. (P.S. Check out our recent blog post on Groupthink for actionable steps on how to prevent this from occurring on your teams!)

For that reason, you may want to consider making part of your estimation process anonymous and asynchronous to make the entire process more bias-proof. (Full transparency, we released a feature called planning poker that will help you with exactly that.)

One simple way to get started with your team is to write down all your story or reference points on post-its or on a digital Kanban board.

Then, ask everybody to privately assign a relative value to each task. If you want to simplify this part of the process, you can start out using t-shirt sizes to measure the relative size of a task, e.g. S, M, L, or XL task.

Doing this helps to focus your discussion, so you can spend your valuable time talking through the story points that had the least alignment in assigned value.

What we’re left with are a collection of clear guidelines that debunk myths around estimation. JJ adds that, whatever you do, avoid comparing your own progress to another team’s. No two scrums or sprints are alike. You also don’t necessarily know how other teams define the value of their story or reference points.

Like JJ said before, keep your eye on progress, not hours. And by all means, give yourselves some grace. Estimation is a practice that’s meant to be repeated and refined over time, just like your code.

This is just a small portion of JJ Sutherland’s insights into estimation myths. You can watch the full webinar on-demand here for all his insights. Learn more about agile estimation techniques here.