Are you managing a long-term project and feel like the basic time-based estimates are not quite working out for your team? Are you searching for an estimation method that would allow developers to consider more factors than time alone in planning their tasks?
Story points are just what you may be looking for.
In this article, you will learn what story points are, how they compare to time-based estimates, and how to calculate them successfully.
Table of contents:
But before we move on to story points, let’s start with answering the fundamental question: why estimate in the first place?
The key reason estimation is important in any project is that it gives us grounds for calculating the project cost based on the estimated efforts, resources, and schedule. Of course, that’s a matter of greater significance from the business point of view, but estimates and the process of estimating may prove useful to everyone on the project team. Yes, this means including the software developers. In Agile, making estimates has two basic benefits:
- it gives everyone on the team a better (and common) understanding of the requirements, the work to be done, and how it’s going to be done;
- it gives everyone more realistic expectations regarding iterations (Sprints) and what can be delivered within them.
As you can guess, though, not everyone in the software development world is a fan of estimates. This is a topic for another occasion, but if you’re curious about a different perspective, check out the #NoEstimates concept coined by Woody Zuill. It started as a hashtag in 2013, and the discussion about the value of estimating and potential alternatives has been going on ever since.
What are story points?
Story points are a way of measuring the effort required to deliver a piece of work. The idea was introduced by Ron Jeffries in the Extreme Programming (XP) framework, but now they are used (and pretty popular) in other Agile frameworks as well. In Scrum, Backlog items are commonly translated into user stories and estimated with story points.
The main advantage of this unit of measurement is that it takes multiple factors into consideration; therefore, the development team can provide more accurate estimates.
The trick here, however, is that story points are a relative sizing method – consequently, they may prove difficult to grasp at first and take a couple of iterations (about 2-3) to implement fully. The Development Team (referred to simply as Developers since The 2020 Scrum Guide) needs both a good understanding of the technique and some time to establish a proper point of reference and figure out the sizing scale in their particular project. Having a clear definition of done is also vital for making better and better estimates.
One way to understand story points is to compare them with simple and familiar time estimates, like hours. We typically measure our work to be done with the time we think it will take us to finish the task. But sometimes, time is not the only factor worth considering. So, let's see what else is there.
Concrete vs. abstract estimates
There are two basic types of estimates:
- concrete (meaning: specific, tangible) – measured with objective units, like hours or days;
- abstract – measured with subjective, relative units whose size is based on a selected point of reference; examples include T-shirt sizes or, you guessed it, story points.
As you can see, the key difference between these two estimate types is how you measure the effort. At first, the concrete estimates seem much easier, but at the same time, they are limited to only one factor (in task estimation, it's usually time), whereas the abstract estimates are a bit less intuitive, but in Agile planning, they may actually reflect the effort required to deliver a user story more accurately, focusing on the size of a given task.
In story points, the size depends on three things:
- the amount of work,
- the complexity of the task,
- the uncertainties/risks.
We'll zoom in on the details of calculating the story point size later. Now, how about we see what their advantages and disadvantages are?
Of course, story points (or other abstract estimates) are not a silver bullet – the estimates are still estimates and subject to change. They may not be the optimal solution for all Agile teams, either. But let's go through the pros and cons of estimation with hours versus story points to give you a more detailed picture, so you can be the judge if they could be a good fit for your project.
Hours vs. story points
Let's start with the more familiar concept: hours.
Estimation in hours
Estimation in hours is a quick and easy option for small tasks assigned to 1-2 people with similar experience; it works well for simple and predictable tasks.
Some risks to consider are:
- Not as precise and accurate as it seems, especially in long-term projects.
- The estimate strongly depends on the person calculating it (their skills, experience, etc.).
- Creates time pressure, which may have a negative impact on the Development Team's work and well-being (the quality and pace of any knowledge work suffer under high pressure).
- May result in over-estimation, over-buffering, and expanding work to the limits of the allotted time (Parkinson's law).
- Typically, they fail to include unproductive work time (natural in everyone's workday: meetings, lunch breaks, coffee breaks, etc.).
- Project sponsors and the finance department may question the estimates ("Why does it take so long?").
Estimation in story points
In the story points method, estimates are decided by the whole development team instead of individual team members, which makes it more credible. Story points are relative, so they enforce planning based on actual team velocity – that is, the number of story points the team can really burn (complete) in a given Sprint.
It’s also worth noting that estimating in story points instead of hours reduces the time pressure.
However, here are some risks:
- Not intuitive, can be difficult to grasp.
- Takes time to be fully implemented and stabilized – to make more accurate estimates, we need to gather measurements on the team's development pace and capacity. Initial insights might take up to 2-3 iterations to be gathered.
- As it's a team effort, it works better in teams in which every team member understands the nature of the work of his or her colleagues.
When to use story points, then?
To sum things up: the story points estimation method is a good option for long-term projects and cross-functional teams in which all team members can estimate story points – the goal is that they arrive at the numbers together, so every developer should have some understanding of all of the tasks. Given some time (a couple of iterations), the team should be able to provide accurate estimates based on their own velocity.
This estimation technique should also take some time pressure off the developers, so if the sponsors pushing too hard on reducing hours are a problem in your project – you might want to give story points a try.
Estimating story points
Now, let's move on to practice, that is: who calculates story points, when, and how.
Who estimates story points, and when?
Story points should be estimated by the people who are responsible for delivering the work – that's why story points are decided by the whole Development Team (Developers).
Estimations should be provided before the Sprint Planning, and it typically happens during Product Backlog refinement sessions. It's the time when the Product Backlog items (PBIs), such as user stories, are broken down into smaller chunks of work to be delivered. Each task should feature a description and a size estimate, and the items should also be put in order. The Product Owner is there to give the team a helping hand in understanding the user stories.
However, if needed, Developers can revisit their estimates for a particular Sprint during the Sprint Planning meeting.
Story point sizes in practice
Here's a little exercise to show you how assigning sizes to story points works in practice. A little reminder to begin with: the task's effort in story points is based on the combination of its workload, complexity, and uncertainties/risks. Mind you, time is not a factor in this kind of estimation.
Let's start with the formula:
Now, imagine that you have a magical piece of paper that can fold ad infinitum (in other words, as many times as you need) and three tasks to do:
|Task||Amount of work||Complexity of the task||Uncertainties / Risks||Story points|
|Task 1: Fold the paper 10 times||This is the smallest task in our Backlog, so we can assume the workload here is relatively small too.||All you have to do here is to fold the paper in half, then in half again, and again, and again... rather simple, isn't it?||This is an easy, repetitive job unlikely to go wrong.||= ??|
|Task 2: Fold the paper 100 times||Compared to Task 1, this task requires much more work.||The complexity doesn't increase: it's still the same operation as in Task 1, only repeated more times.||The risks here are pretty much the same as in Task 1 (remember, this piece of paper can easily fold as many times as you want).||= ??|
|Task 3: Fold the paper into an origami swan||We can easily tell that the amount of work compared to folding the paper 100 times in Task 2 is smaller.|
Folding a swan is much more complex than simply folding a piece of paper in half.
|If you've never folded an origami swan before, uncertainty and risk grow higher.||= ??|
Now, how to calculate the story points?
Story point estimates are typically represented with Fibonacci sequence numbers (brief reminder, these numbers grow exponentially, so we have: 1, 2, 3, 5, 8, 13, 21, 34, etc.) or modified Fibonacci sequence numbers (0, ½, 1, 2, 3, 5, 8, 13, 20, 40, 100). You can also use the Power of Two or other numerical systems, but the trick is to ensure that it adequately shows proportions.
The general rule is simple: the bigger the effort required to complete a task, the bigger its assigned number. What is important is to agree on a size reference so that everyone on the team is on the same page as to the scale.
How to set the proportions for sizing?
First, pick your size reference. There are two ways to do it:
- Select a medium-sized task from the Backlog and give it size 5, or …
- Select the smallest task in the Backlog and give it size 1 (or ½) ...
… then estimate the rest of the tasks in comparison with the medium-sized or smallest one, depending on your choice.
Now that you know how to calculate story points, what are the numbers you would assign to Task 2 and Task 3? Why? Feel free to leave your answers in the comments section.
Perhaps the most commonly used way for calculating story points is Planning Poker. The main advantage of this technique is that nobody is influenced by other team members: everyone shows their cards, that is – their estimates, at the same time.
How does it work exactly?
- Each Developer receives a pen and a set of cards (or their virtual equivalent).
- The team takes a Product Backlog item.
- Developers briefly discuss the item if needed.
- Everyone comes up with his or her estimate (a number) but keeps the “card” to him- or herself – just like they would in real Poker.
- When the whole team is ready, everyone reveals their card.
- When the estimates are the same, the situation is clear. If the estimates are different, it's discussion time!
- Once you reach a consensus, it’s time to write down the calculations. That’s it!
Best practices for story point estimation
Below, you will find a couple of good practices you can use when estimating with story points.
- When the estimates in Planning Poker are very different from each other, it’s a good idea to ask the people who proposed the smallest and biggest values to explain their way of thinking first.
- Don't forget to discuss incorrect estimates during your Sprint retrospective to investigate what happened and how the team can improve their calculations in the future.
- Don't compare story points between different development teams – each team has its own velocity.
- Don't translate story points to hours or days; you'll miss the whole point of relative sizing.
- The teams shouldn't adjust their estimates during the Sprint – if they turn out to be inaccurate, that's a matter to investigate and learn from during the Sprint retrospective.
Story points wrap up
To cut a long story short: story points are a method of estimating the effort required to deliver a Product Backlog item in Agile projects. While hour estimates represent the time required to complete a task (e.g., a user story), story points represent multiple factors, such as the required workload, the task's complexity, and potential risks. Story points are decided by the development team.
Though they may seem difficult at first, in the end, they may enable the Development Team to provide more accurate estimates. As with any other method, story points come with their pros and cons – their main advantage is that the estimates are decided together by all Developers in the project, relative, and based on multiple factors. The key to successfully implementing story points is to make sure the whole team understands the concept – in the Scrum framework, it's typically the Scrum Master's job to teach and guide the team and facilitate planning sessions.
Are you Team Hours or Team Story Points? Or maybe team #NoEstimates? Share your thoughts in the comments.
If you need experienced Agile project management experts (Project Managers, Scrum Masters, Product Owners) for your software development project, don't hesitate to reach out to Codete – we'll be happy to give you a helping hand.