Story Points
Story Points are not part of the SCRUM framework.
To explain Story Points and why they can be helpful, let's first look at where they came from...
Ok, But What are Story Points?
Story Points are a way of estimating a piece of work that encompasses both the volume of work and it's complexity. They do not state how long a piece of work will take to develop.
They are used to plan and prioritise work, with the understanding that they do not represent how long a piece of work will take.
User Stories / Backlog Items
Stories are an idea taken from XP (Extreme Programming). XP is an agile framework with the aim of producing higher quality software and a higher quality of life for the development team.
XP introduced the concept of Stories as pieces of work. When managers and others starting taking story estimates as the amount of time that story would actually take, simply by misunderstanding the nature of the estimates, then a new system was suggested that simply called these estimates Points. This abstraction away from time can prove useful to avoid unhelpful noise around how long a piece of development work would take.
SCRUM practitioners, recognising the value of using points on backlog items adopted both the idea of calling backlog items user stories and of adopting the estimation term Points as Story Points.
In SCRUM, Why Use Story Points Instead of Estimating in Days?
So, if SCRUM doesn't say to use Story Points for estimates, why do so many teams use Story Points?
There's a few reasons why people use Story Points:
- They wrongly think its part of SCRUM and as such don't have a choice
- They're told to, so think they don't have a choice
- It's what the team did before they arrived
- An online search says that's how you estimate user stories
- or maybe, they really understand the benefits and limitations of using Story Point estimates and think its the best way for the team to estimate
What are the some of the Benefits of using Story Points?
Cross-functional teams
In a cross-functional team that consists of team members with different skills and abilities, it may be very difficult to come to a consensus of how long a piece of work will take. It may take one team member 1 day, a different team member may need 5 days to complete the same piece of work. If one gave an estimate of 1 and the other an estimate of 5, then they are both correct. At the point of sizing we probably don't want to allocate who will be doing the work (as it reduces team flexibility later on).. so it's an impossible situation to resolve without ignoring one person's perspective. When we use story sizing instead, its easier for a team to agree that this story is about the same size and as complicated as this other story that was X points.. so this should also be X points in size. With this agreement we can get true commitment from the entire team on trying their best to complete their Sprint Backlog.
Using Story Points has several other benefits:
- The default Fibonacci numbering system has built-in uncertainty that prevent the team from being pressured into producing falsely accurate estimates
- By abstracting estimates away from time, we break the comparison between estimated time and delivery time and many of the unhelpful interactions that follow
- It is possible to prevent the direct comparison of one team's performance with another team's performance. Doing this sort of comparison can become a very unhelpful interaction with a team as the skills and experiences within every team are unique
So What's with the Strange Numbering?
To Fibonacci
Typically, when estimating in points, we use a Fibonacci sequence for the lower end numbers: 1, 2, 3, 5, 8 and 13. and then switch to whole ten's of numbers going onwards like 20, 30, 50, 80 etc..
(The Fibonacci sequence starts with 1 and 2 and then each subsequent number is the sum of the two preceding numbers.)
Why not just use 1, 2, 3, 4, 5, 6... etc? This would mean that if you think a piece of work is 4 points, then you could just give it 4 points, instead of rounding it up to 5!
The important aspect of the Fibonacci sequence is not the numbers themselves, but the ever increasing gaps between the numbers. The idea behind these every increasing gaps in numbering is an acknowledgement that software development is complex. With complexity comes uncertainty. There is the hope that if a piece of work is small, then the uncertainty will be small and as a piece of work gets larger, or more complicated, the level of uncertainty starts to increase.
The other aspect of these ever increasing gaps in numbering comes back to Weber's Law which states that a difference in something is only perceivable to someone in proportion to the something being measured. For example, you could probably very easily tell the difference between a 1KG and a 2KG weight pretty easily; do you think you'd be able to tell the different between a 20KG and a 21KG weight?
The Fibonacci numbering sequence seems to reflect both of these quite well (as would a doubling scheme). The reason we don't persist with Fibonacci at the higher level estimates is that an estimate of 21 points seems rather precise. In order not to fall in the trap of this false precision (because these larger estimates have a high level of uncertainty), we quickly abandon the Fibonacci sequence and just round in 10's... making the gaps larger in the same way as the size increases. 20 points seems to be a much rougher estimate than 21 points.
Or Not to Fibonacci
In summary, if you understand why we use The Fibonacci Sequence for estimates (rounding estimates up), then you'll understand when it's reasonable to not use this numbering for estimates. Or, at least, you'll know when the team ask to use a different way of estimating what the benefits and pitfalls may be.