Understanding Agile Story Point Estimation, and Why It’s Worth the Effort

For almost any Agile organization, teams use story points almost every day. People make business forecasting and even financial decisions based on what these story points tell management about the future of new and ongoing projects. Have you ever wondered whether you can, or should, really rely on those story points? I’ve found that many Agile teams lack a working knowledge of how to estimate story points accurately. The fast pace of business, the nature of the disruptive ways many of us work, and many other factors contribute to the problem. Sometimes this happens because people assume that the way a team estimates story points is the right one and never ask why it is done that way. Sometimes, no one takes time to explain the process. Over time, this can erode the usefulness of story points, and erode an organization’s trust in them.

Try this test: grab a story from your team’s backlog and ask someone why it has the number of points it has. If the answer is something like, “Because it’s ‘x’ days of work,” or “Because it feels like it!” then this blog post may be of help to you and your team. I will discuss the importance of story points and elaborate on four key elements that will help your team with consistency and efficiency during the story point estimating process.

 

Why Do We Use Agile Story Points?

Historically, people have most frequently used hours to estimate work. In software development, we sometimes use other approaches, such as function points or lines of code. None of these methods proved to be accurate enough or easy enough to use daily. 

Most of us find it hard to estimate projects because each team member has different skill levels and capacities. Each person works at different speeds. Work that one programmer can finish in four hours may require another person at least eight hours to complete. How can we agree on an estimate if the perception of the work at hand is so different?

Agile story points provide a very useful and powerful alternative. Let’s take a close look at Mike Cohn’s example on estimating story points.

Within this example, Mike Cohn asks you to imagine two runners, one who is quite fast and the other who is slow. They both plan to run a 5-mile trail. The fast runner estimates he can complete the trail in 30 minutes, while the slower runner estimates it will take him 60 minutes. They try to agree on how long it will take to finish the trail, but the slower runner cannot just double his pace. Nor does it make sense for the faster runner to slow his pace. Mike Cohn points out that there is a more abstract measure that can be used, the required effort to finish the trail, which in this case is five miles. They still don’t agree on the amount of time it will take, but it loses relevance because their new abstract measure is also relative.

The relative measure is important for estimating future runs. For example, if next week these runners decide on a 10-mile trail, they can agree that as the trail is twice as long as the 5-mile trail, the amount of effort will double. Now, it won’t matter if one could run it in 30 minutes while the other could run it in 60 minutes.

It’s the same for story points. We use story points for two main reasons:

1. Story points are abstract, so people with different skills and speeds can agree on the points required.

2. Story points are relative, so we can easily decide the estimate of new tasks by comparing with previously estimated tasks and saying, for instance, this is twice, half or two-thirds of the size of a similar task we valued in the past.

 

How Do We Estimate Using Story Points?

To properly estimate using story points, we must first acknowledge that estimating requires a lot more than picking a number based on intuition.

Teams frequently oversimplify estimates by limiting their thinking to how big the task is or how complicated it seems. In reality, there are four very important considerations: volume of work, complexity, uncertainty, and risk. You should consider all these aspects if you intend to estimate story points as accurately as possible.

 

Understanding the Components of a Story Point

Think back to the example of the two runners. We can say that the runners estimated based only on volume of work, because the only factor that was observed was distance. This is usually the first aspect that comes to mind when estimating.

Now let’s assume that those two runners gather to do another run, but this time on a mountain trail. They choose a 5-mile path that they know very well. Even though they already estimated a path that was equal in length, this time the effort will be greater and they will end up running for more time because mountains inevitably entail more complexity. So, they decide that this task should be eight points instead of five as the original 5-mile run. Notice that this estimation is already a combination of two elements.

What happens if those runners feel adventurous and decide to run on a mountain they have never run on before? This time the uncertainty of what they may encounter is a factor. They may experience difficulties like crossing a river with slippery rocks where they have to slow their pace. Even though they have the reference that running 5-miles across a known mountain trail demands an effort of eight points, they assign an extra three points to account for that uncertainty.

Lastly, let’s assume weather is known for being extreme and unpredictable in the area. This can make things even more challenging. They know about this added risk and they can increase the estimated effort by, let’s say two points, or just acknowledge it and leave it as is. Unlike uncertainty, risk is about situations that we can predict, manage, and measure to some degree. In this analogy, the runners don’t know the mountain at all (uncertainty) but they know about the sporadic weather behavior (risk).

The thirteen points we ended up having for this quest are the result of putting together five points for the amount of work, three points because of the added complexity, three points for the high uncertainty, and two points because of the identified risk. Combining all four factors has led to the most efficient estimation. 

 

How to Estimate Using Baselines

In the previous scenarios, every new decision feeds from previous estimates and known facts that serve as references to make informed decisions. The same should apply to our projects each time we estimate.

The idea is to take two stories that are crystal clear for the team, ideally, one small and one that is larger, let’s say a story estimated at two points and a story estimated at five points. You would use these to estimate future stories by comparing the four factors described above. 

For example, let’s say the team reviews a newly created story and thinks that, while it is very similar to the two-point story used as a reference, it has considerably more uncertainty (but still not so much as to require the effort of the five-point story). They could estimate the new story as a three-point story.

 

Practice This Simple Approach to Improve Your Estimating

Keeping story point estimates focused on these four key elements can help your Agile teams consider multiple factors while still expediting the estimating process. This approach reduces ambiguity and arbitrariness. That’s especially useful if your team or project is new. It can also help reduce inflation of estimates in established teams.

Here’s a helpful tip: write the four factors on a notecard. Maybe draw a relevant image that triggers in your mind the significance of each factor to get used to thinking about them quickly. Take your card to every story estimation meeting. After a few sessions, you’ll find the process more intuitive. You’ll also find that your estimating will improve significantly.

Now if someone asks you what led to estimating a story as five points, you’ll be able to explain. And you can share these techniques with your teams, so they’ll also know how to estimate Agile story points efficiently and accurately.