As someone once said, “It’s hard to make predictions, especially about the future.” But estimating work to be done is all about the future. How can Agile teams go about it, especially when the Scrum Guide does not give much detail about it? It is left up to the development team to choose an estimation approach for themselves. The most popular approaches they can go for are story points and hours.
What are story points?
Story points (SP) are comparative units of measure. Agile teams use them to express estimates of the overall effort they will need to fully implement product backlog items (develop user stories). Therefore, when you estimate story points, it really means you estimate effort and assign a point value to each backlog item.
Story points are relative to another value
Story point is a relative unit because it exists only in relation to another value. For instance, if a task takes two story points to complete, it means it needs double the effort as a task with 1 story point. Similarly, a 1-point task will take one-third of the effort in comparison to a task estimated at 3 story points. Instead of linear 1 and 2, you could use Fibonacci sequence values to express the effort. Whichever you pick is up to you and your team. What really matters is the ratio between the story points and the relative values which is far more important than the actual numbers you assign to Agile story points.
Story points are relative for each team and team member
There is one more dimension to the relative nature of story points, namely the efficiency of the team that makes estimations. Skill level, experience, familiarity with given tasks, and many other factors set apart one person from another. It means that for one team, a certain backlog item could be worth 5 points, whereas for another only 3. The same applies to individual members of the team—junior and senior will also perceive the “size” of the effort needed for a given task differently.
Story points are the sum of multiple factors
The effort is the sum of multiple factors and your team must consider those factors in their story point estimates. They include:
- Amount of work. More work takes more effort, thus it is worth more story points.
- Complexity of work. The difficulty level can greatly affect the effort.
- Risks and uncertainties. External stakeholders, legacy code with no automated tests in place, unclear requirements—these all could be a source of risk that your team will have to address (i.e., put more effort).
Also, since story points are relative, the value you assign to similar tasks could change over time due to another factor: repetition. As such, the experience level of your team in dealing with the same or similar tasks will also influence the “size” of the final effort.
Estimating with story points
How are story points calculated? Essentially, story points calculation is based on a comparison of features of one project with features of a previous similar project. Such an approach allows the team to understand the difficulty of a particular feature. It also lets them assign a numerical value indicating a particular feature effort.
What if the team performs effort estimation for the first time?
In such a case, a team needs to identify a baseline story. It does not necessarily have to be the smallest one, but something that resonates with everyone within the team. Once the baseline story is in place, the team can begin story points estimation by comparing them against the baseline.
Let’s illustrate this approach using circles as a simple example.
Circle A is clearly the smallest one. B is about double the size of A. Whereas C is roughly four, maybe five times bigger than A, and two times bigger than B. Here, we do not have precise absolute values to assign to each circle. Yet—we managed to estimate their sizes using relative values by using circle A as the baseline.
Story points sizing
In Agile approach, instead of circles, teams work with user stories. By comparing user stories with each other, teams can determine the relative size of one story in relation to the other and assign them story points. Of course, this method applies not only to user stories but also to requirements formulated in any other form.
Now, you might be wondering: how should you scale the relativity ratio between individual user stories? Naturally, the larger the user story is, the greater the difference must be between them. Otherwise, it would be difficult to perceive and determine which object is really bigger and by how much. Let’s illustrate this concept using circles again.
There is a notable difference between A and B, as well as between B and D. But when you look at D and E, the difference is very subtle and you are unable to tell by how much both of these circles differ. That is why many Agile relative estimation techniques take different scales (sizings) to express story point values:
- Fibonacci sequence where each number is the sum of the previous two in the series (0, 1, 2, 3, 5, 8, 13, 21, 34, 55, 89, …).
- Linear sequence where you get from one term to the next by always adding or subtracting the same amount (e.g., 1, 2, 3, 4, 5…; or 3, 6, 9, 12, 15, 18, …).
Fibonacci sequence vs linear sequence for story points estimation
Using linear sequences can be tricky. Why? Because not all of your team members might fully understand the subtle difference between two consecutive sizings.
For example, it is difficult to gauge the difference between a task that takes 5 SP and one that takes 6 SP (an increase of 20%). However, the difference becomes clearer between a task with 5 SP and with 8 SP. This is a 60% effort increase (for that reason, the Fibonacci sequence is the one popular scoring metric).
Moreover, although the absolute difference in the lower end of the scale is small, the relative difference is high. For example, the absolute difference between 1 and 2 is barely noticeable. But the relative value between these two is clear (2 SP task takes twice as much effort as 1 SP task).
Benefits of using story points in Agile
Story points allow software teams to make story estimations relative to each other, without considering time. This gives them not only a lot of flexibility but also a range of other benefits.
Fosters team collaboration
Story points allow team members who perform at different speeds to communicate and estimate together. For example, if one team member estimates a task for 5 story points, but another estimates it for 8, it opens up an opportunity for the team to discuss the work in detail.
Bring multiple teams together
When organizations scale Agile, they face the challenge of managing multiple teams. Teams that work on the same project will also need to become part of the estimation process. Therefore, they will need a baseline for estimating their work. And story points can provide that baseline.
Increase productivity
When teams base their estimations on hours, they tend to prioritize task deadlines over the implementation goals. Story points fix that issue as they are about the effort, not time. Such an approach helps teams focus on solutions and improving product quality instead of tracking their time.
Tracks velocity
Velocity reveals how much product backlog effort an Agile development team can successfully handle in one Sprint. Velocity, just like story points, is a relative value. It means it can change over the course of the project. And when it does, you do not need to recalculate your story point estimates. This would not be the case if you had made estimations using man-hours.
Help to plan future Sprints
Story points and velocity based on them provide reasonably accurate data. It allows leaders to better manage their stakeholders’ time expectations in relation to future work.
Story points vs hours
Why do most of the Agile teams and practitioners recommend estimating with story points instead of (un-Agile) hours? The main reason is that it is incredibly difficult to precisely estimate how long it would take to complete a given user story. Your team could get their hour estimations right for the easy or repeatable stories. But as the complexity and effort of the story grow, time estimation becomes trickier.
On the other hand, it is much easier to consider two stories and say, “The first story is easier to implement than the second one because it has very straightforward requirements. The second story is more complex and risky.”
Furthermore, time estimations carry emotional attachment. Let’s say you estimated a task to take 6 hours and you ended up doing it for 10 hours. How would you feel about it? And what would you tell your manager?
So, the bottom line is that, as humans, we are pretty bad at absolute estimations. It is easier for us to say a task will take more or less effort compared to another task—especially when there is a great deal of complexity and/or uncertainty involved.
So does it mean that story points are better than hours? It depends as neither of them is perfect and comes with some drawbacks.
Challenges with time estimations
The traditional and most common approach to measuring teamwork is by using absolute values such as man-hours, days, or weeks. It relies on an estimate of how much work one person can complete within one hour. Although you can easily measure it, the time metric is not always the best option to go for. Here’s why:
- Precise hour estimation is impossible. This could be due to several factors, such as dependencies certain tasks carry or because they were not defined too well.
- Hours are individual to one person. If one developer starts a task and someone else finishes it, the time estimate is no longer valid. That is because another developer is likely to take less or more time for completion, based on their experience and expertise level.
- Time estimates do not factor in extra work. Let’s say a developer considers possible risks to occur during the task and adds extra hours to their time estimation (just in case). As a result, they could end up finishing their task earlier (or later depending on the effort) which will ultimately prove their estimations wrong. Similarly, hour estimates do not account for any non-development work such as time spent in meetings or answering emails.
Challenges with Story Points
While story points might seem a solid alternative to time estimates, they are not perfect either.
- Story points are hard to grasp. Developers often do not understand the abstract notion behind story points. Some team members might prefer more precise and tangible definitions of estimates.
- They are individual to one team. Story points are relative metrics and you cannot use them to compare one team’s velocity and story point estimation with another.
- Estimating with story points can be a tedious process. It involves a whole team; finding the base story or stories; comparing one story to another; figuring out the suitable size scale. However, once a team agrees on the relative effort of each story point value, they can quickly assign points to user stories.
Teams for which story points do not work too well can use other relative or absolute metrics to calculate their efficiency and scheduling Sprints. They can use time estimates in hours or no estimates at all. All in all, story points are a helpful metric, but not the only available so pick the one that works best for your team.
