Story points estimation is an estimation method that is often used in agile software development.
Story points are a unit of measure used in agile project management to estimate and compare the complexity, effort, and relative size of features or user stories within a project.
Instead of providing precise time-based estimates, teams assign story points collaboratively, employing a relative sizing approach. This methodology allows for a more flexible and adaptive project planning process that acknowledges the inherent uncertainty in software development.
Agile methodologies, such as Scrum, commonly employ story points as a way to facilitate more accurate and consistent estimation of work.
Relative Sizing
Story points work on the fundamental principle of relative sizing. Rather than asking team members to estimate requirements in days and hours, Story Points instead focus on determining the relative sizing of tasks.
Anecdotally, it’s easier to say whether one task is larger or smaller than another; however, accurately predicting the exact time involved in each task is significantly more difficult.
Story Point Scale
There are a number of different scales that can be chosen for modelling story points. The most common scale is the Fibonacci sequence.
The Fibonacci sequence is non-linear, where the gap between each successive number increases as the sequence progresses
1, 2, 3, 5, 8, 13, 21, 34, 55, 89, 144, …
The non-linear quality of a story points scale is important – because this models the uncertainty and variability in attempting to estimate work of different sizes.
For example, if one task is an 8, and another task is a bit more work, if you were using a basic linear sequence, you might say the bigger task is a 9. However, how accurately did you estimate the 8? How accurately did you estimate that the bigger task is only “a bit more work”? With a non-linear story point scale, you’re forced to pick the next non-linear number. So if it’s bigger than an 8, it has to be at least a 13.
Whilst the Fibonacci sequence is the most popular scale for Story Points, Powers of 2 and Modified Fibonacci Sequence are common alternatives
- Powers of 2
2, 4, 16, 32, 64, 128, 256, … - Modified Fibonacci Sequence
1, 2, 3, 5, 8, 13, 20, 40, 100
The Fibonacci sequence also has an interesting quality that is related to Weber’s Law which is a hypothesis in the field of psychology that relates to human perception, more specifically, the relation between the actual change and the perceived change.
“the just-noticeable difference (JND) between two stimuli is proportional to the magnitude of the stimulus”
In simpler terms, Weber’s law states that a noticeable difference in a stimulus is a constant ratio of the original stimulus.
We can explore Weber’s law with an imaginary scenario.
Imagine you are carrying two weights – a 1kg weight and a 2kg weight. It is easy to determine which is the heavier of the two – after all, the 2kg weight is 100% heavier (twice as heavy) than the 1kg weight.
Now let’s imagine the same scenario but with a 20kg and 21kg weight. The difference is still 1kg, however, it is harder to distinguish between the 20kg and the 21kg weight. Even though the absolute difference in weight is still only 1kg, the 21kg weight is only 5% heavier than the 20kg weight. On the other hand, if we were to have a 20kg and a 40kg weight — the difference becomes noticeable.
If we translate this to estimation using the Fibonacci sequence, it will look a little like this. As the complexity of a task or feature increases, the difference between estimated story points for a team to perceive a change also increases, with the ratio of the change in points to the original estimation remaining consistent.
The Fibonacci sequence satisfies the consistent ratio of change aspect of Weber’s law as there is a roughly ~60% ratio between each increment.
Collaborative Estimation
Estimation of story points is often a collaborative exercise. If, for example, a team using the Scrum agile methodology, the team will collaboratively estimate each user story during a Sprint Planning session.
This process ensures that multiple perspectives are brought together to consider the complexity, interdependency and risks associated with delivering the story. Equally, the estimate is likely to be less sensitive to a specific individual performing the task, as the agreed estimate is a team consensus.
This process of collaborative estimation fosters a sense of ownership and shared responsibility among team members.
Velocity
Velocity is the amount of work that a team can achieve in each increment. Therefore, if we are following the Scrum methodology, our team will be working in sprints of a fixed size, typically between 2-4 weeks.
If a team is able to complete 50 story points in a sprint, this would set their velocity at 50 story points. The measure of velocity is a historic measure, which you need benchmarked data for.
The velocity of one team will not be the same as another team. Even if the team is the same size and the sprints are the same length. This is because the process of story point estimation is entirely relative, they are a relative measure of task complexity, and they are a relative measure of how much complexity a given individual or team can tackle during a finite period. For instance, a senior developer may have a higher individual velocity than a mid-level or junior developer – allowing for differences in experience.
Therefore, it is only after the first sprint that you will have a true measure of velocity. And ideally, as time goes on this measure of velocity will be based on an average taken across multiple sprints.
The team will also gain an understanding of how their velocity will be impacted by things like vacation time or non-development activities.
But can you relate story points back to time?
Some die-hard agile purists will refuse to convert story points to time “because story points aren’t about time”. And they’re right – story points are designed to be a much richer representation of total effort.
However, the reality is that the business world plans and sets strategies based on quarters and yearly targets, so you’ll never get away from needing to project a project’s performance in absolute terms.
You can legitimately translate story points to time, provided you understand the caveats:
- Each team will have its own velocity, which means that story points at a team level will have a different meaning from one team to another
- Individuals within a team are likely to have their own individual velocity – a more experienced developer could have a higher velocity than a more junior one. Which means one developer being on vacation is likely to have a different impact to another.
Summary
Story points are just one approach for estimating software requirements and functionality, however, Story Points are well suited to the delivery of software using an agile methodology.
Development teams often favour working with story points because they’re a measure that recognises the inherent uncertainty in software development.