Understanding Story Points in Agile

If you’ve ever been to Beirut (or Cairo for that matter), you know that the time it takes to get anywhere in the city is subject to so many factors other than distance. Traffic could be extreme, or not; the rain could flood the city, or not; construction, road blockage, time of day, random threat somewhere, overall feeling of the population, and so on, are all variables you’d have to consider.

Similarly, the items in your product backlog are subject to a number of variables, which makes agile planning not as straightforward as one may wish it to be.

The basics of using story points

So what is a story point anyway?

A story point is a metric, more abstract than say ‘an hour’, used in agile project management to figure out the implementation difficulty of a certain user story. Fundamentally, it's a number that tells everyone on the team how challenging a story is, based on factors such as its complexity, risks and efforts involved.

How are story points decided upon?

Typically, story point estimation happens during product backlog grooming sessions with development and testing teams looking into the product backlog. The product owner and team will try to ‘groom’ the backlog before sprint planning happens; if you’re interested to know more about backlog grooming sessions, here’s a useful article.

Why would developers use story points?

Estimation is hard, especially for software developers; so many factors have to be taken into account as product owners make decisions that affect the entire team. Story points are meant to make estimating easier, and so instead of estimating in hours, teams look at how much effort a product backlog item will need relative to other items; hence the term relative estimation.

How to estimate story points

Story point estimation is based on three main components:

• Risk includes demands that are vague, dependencies and random changes.
• Complexity is related to how difficult a feature is to develop for example.
• Repetition is determined by how well the team member knows a feature and how monotonous the tasks are.

3 steps to estimating story points

Step 1 — Use Fibonacci sequence numbers

When we observe the geometry of plants, it’s easy to recognize recurring patterns in nature. I won’t delve into the details of this fascinating play of mathematics, but if one sees math as the language of the universe, well, the Fibonacci sequence is a brilliant representation of that.

Why Fibonacci and not a linear scale?

There are two types of scales used for creating estimation matrices: the linear scale and Fibonacci sequence.  The latter is used when estimating absolute values is difficult such as estimating the exact number of hours required for a given task. Now, as tempting as it is to assign items with a linear scale, it seldom works for story points.

It’s like trying to differentiate between 7 and 8, as opposed to 5 and 8; the latter difference is simply more pronounced. To put it this way, the Fibonacci sequence is used when we're looking for a better estimate of the complexity of a project. But keep in mind that you can still use a linear scale if you’d rather that; many do.

The Fibonacci sequence is a series of numbers with each number being the sum of the two previous numbers: 0, 1, 1, 2, 3, 5, 8, 13, 21 and so on. For Agile, the sequence is typically modified to 0.5, 1, 2, 3, 5, 8, 13, 21 and so on.

Step 2 — Create a story point estimation matrix

Your baseline is hereby included in the matrix as 1; this represents the story that has the least amount of risk, complexity, and repetition. From there, you start building the story point estimation matrix or estimation table as a way to measure effort more concretely, not just with respect to time. Once the first story point is set, you can fill the table with other stories in relation to this first. Each story point value may have more than one story connected to it.

Step 3 — Play planning poker to decide on story points

Planning poker is a great way to have the team agree on the correct story point approximation for every item in the backlog.

• During the sprint planning meeting, each developer receives a set of cards depicting the Fibonacci sequence.
• The backlog item is then brought to the table to be discussed and clarified.
• Each developer and tester privately gets to select the card they feel reflects best their estimation for that item.
• The estimators reveal their cards at the same time and once consensus is reached amongst the whole team, then we move on to the next backlog item.

It’s useful to set a maximum limit beyond which tasks can be split into smaller items. Also, if a task is smaller than 1 or 0.5, it can be incorporated into another task.

By the end of priority planning poker, the matrix should be filled and tasks divided into rows based on their story points.

How to convert story points into hours?

If you’re wondering how to convert size estimates into hours, let us wait until the first sprint is over so we can track team velocity as it progresses. Remember, Agile is all about iteration.. As soon as the first sprint is done, we’ll know how many story points a team can complete per sprint, which then allows us to forecast the team’s performance for the next sprints.

Given all backlog tasks are already estimated in story points, we now know how many sprints we will need to complete the project and convert these abstract units into real timelines.

Story point benefits and common mistakes

What are the obvious benefits of using story points?

• Estimating with story points in Agile is quick and accurate, and offers understanding when it comes to the relative effort required for stories that you’ve never dealt with before.
• Estimation is relative to already completed product backlog items in the first sprint.
• Story points allow you to estimate without giving specific time commitment.
• They help embrace the uncertainty that tags along with estimation; it is what it is.
• Story points are accurate enough to plan sprints ahead, allowing you to better manage time expectations for future work.

Common mistakes to avoid when using story points

• Story points represent complexity, uncertainty and risk together, and should not be influenced by one variable alone.
• Sometimes when translating story point to hours, we get a false sense of accuracy.
• Avoid averaging story points; the idea is not to be 100% accurate, but accurate enough to be able to plan ahead of time.
• Do not story point bugs that are part of the original estimation.
• Avoid story pointing small tasks that are easy to estimate time-wise.
• When developers leave the team, don't forget to establish a new reference to make sure everyone is on the same page given the work context has changed.
• Estimation is a team effort, so make sure it stays that way.
• Don't ignore story-pointed issues that were made incorrectly; use the retrospective to discuss them.
  

The concept of story points is really simple, and quite realistic in a world where uncertainty is the one certainty. And though critics love to point out the drawbacks of Agile and how it lacks discipline compared to the traditional waterfall model, one can no longer deny how much more sense it makes.

Story Points FAQs