Story points: what’s the point?

1 November 2018 | Anikh Subhan | About a 4 minute read

Story points are a set of values that are used to signify how complex a piece of work is, and they’re generally an output from when a team estimates some upcoming work. Estimation in an Agile world can be a highly contentious and challenging topic. Some people would argue that estimation is not needed, necessary or possible (#NoEstimates). Others might say that estimates are essential to carry out long-term planning, set deadlines and manage expectations. In my opinion, the answer (for most teams) is somewhere in the middle.


My goals for Agile estimation…

  1. The estimation process is carried out, primarily, for the team to get to a better understanding of how they will tackle the work.
  2. The whole team generally agree on how they will do the work.
  3. It provides a rough idea of complexity and sets high level expectations with the Product Owner and stakeholders.

If these goals are met, then it’s good progress towards successful estimation. In order to estimate in an Agile fashion, there are different units that can be used – one of them is story points.


What are Story Points?

Story points are a set of numbers that are used as a metric to understand the scope and scale of the work, compared to other pieces of work. The key things that are considered by a team when estimating are: risk, uncertainty, amount of work and complexity. The range of numbers that we generally use at AND Digital, are based on an adjusted Fibonacci sequence and are as follows: 1, 2, 3, 5, 8, 13, 20, 40 and 100.

The lower range of numbers are usually used for types of work that are very well understood. The team should be fairly certain about how they will do the work, and how difficult it will be. It might be a piece of work that is similar to something that’s been done before. A story with a low and granular size implies that the team have a lot of detail on the story, it’s quite predictable and that it has been scoped out well.

The mid-range numbers allow for a little more wiggle room. The actual numbers that a team end up with are not really important. What’s most important is the relative estimate of each story compared to the others. The relative ratios are what help a team and Product Owner prioritise and organise their work effectively, so they know how much effort a feature is compared to the value it might deliver.

Towards the higher end of the scale, we have some huge numbers! These are for unclear, fluffy, unpredictable items in the backlog, that have not yet been fleshed out. Between 20, 40 and 100, there is not much opportunity to worry exactly which number is used, but just enough to signify how big, scary and uncertain a piece of work might be, relative to other stories.

We also have the “?” and the ‘Coffee’ values for when someone doesn’t know enough about a story to estimate, or they need a break!


So what’s the point in Story Points?

The biggest benefit of using this measure is that it enables a team to have a structured discussion about upcoming work. It encourages healthy debate, conversations and collaboration in order for everyone on the team to be on the same page with what, why and how they will approach their work.

Story points help to abstract risk, complexity and amount of work away from time. Attempting to estimate these things in terms of hours or days will end up in wrong sizes, wrong expectations and possibly unnecessary, unhealthy tension between the team and their stakeholders. Estimation of software engineering itself is a highly inaccurate thing. So to try and use a highly accurate measure like time, generally ends up in a mess. Certain stakeholders might prioritise a feature because it’s estimated at 2 days worth of effort, but when it takes 4 days, for valid reasons, the team’s credibility is damaged, even though they may have kept the stakeholder informed throughout. These kinds of interactions can end up with comments like, “The team need to become more accurate at estimating in time”. Estimating in arbitrary values, but relative to each other, ensures the team are focused on discussing the work involved rather than debating the time it may or may not take. The relative sizing then allows the Product Owner to prioritise whatever work they want into a set capacity, or Sprint.

It’s also a very good technique to use for a new team, or when a team has new members, in order for them to get used to the various types of work, and how complex they are. As the new team estimates work, then executes the work, they will learn and get used to how complex a feature is compared to everything else. This helps with future planning as they become accustomed to what the sizes actually mean in terms of work.



Story points are a great tool for teams to estimate their upcoming work. Depending on the environment and expectations of the team, once they become stable, mature and experienced, they may choose to evolve from using story points into something more flexible and loosely structured, such as T-shirt sizes, or even measuring the average time taken for user stories to be completed (cycle time).

Read More From This Author

Share this blog post

Related Articles


We’re looking for bright, dynamic people to join our team!

Discover More Roles