There is a common misconception, especially among those new to Agile/Scrum, that Story Points are just another way of measuring how long work will take and can be easily swapped out with hours. A common mistake new Agile/Scrum practitioners will make is to hand out a matrix that new practitioners can use to easily map the hours of old to the new points system. This approach entirely defeats the purpose of story points.
Old Way |
New Way |
| 2 hours |
1 point |
| 4 hours |
3 points |
| 8 hours |
5 points |
| 16 hours |
7 points |
| 24 hours |
11 points |
Don’t do this…
Why Use Story Points?
Estimating work using story points solves the age old development problem of having different people write the code than those who estimated the work. For example, if you have a tenured, senior level engineer that estimates the work for a given project or sprint then a brand new engineer, fresh out of college, the new engineer is very unlikely to complete the work in the estimated timeframe, even if the senior level engineer padded the estimate to account for this. The problem is that we tend to be only moderately good at estimating things for ourselves and tend to be terrible at estimating them for other people. This is why most software projects and other forms of construction are often late.
Story points give us a way to measure work such that the experience level and speed of the person doing the work does not have a material bearing on the estimation process.
Story Point Basics
The hardest thing for new story point estimators is getting their head around the fact that story points do not measure duration. Instead, story points are used to measure size. By measuring size engineers are able to find a common ground that they can all agree on, even if it will take each person in the group a different duration to complete a task of the same size. Let’s explore with an example.
Story points measure size. For example, 1 mile. Minutes (hours with code) measure duration, or the amount of time it would take you to run 1 mile. Bob is not a very good running and it takes him roughly 15 minutes to run 1 mile. Swathi, on the other hand, is an excellent runner and can run 1 mile in just 6 minutes. The size of the task is the same but it takes each runner a different amount of time to complete the task.
If you translate this concept to software the team starts by forming an agreement for the size of various size tasks (more on this later). For example, adding a text field to a page may be 1 point, adding a new page may be 5 points, and adding a brand new user role may be 13 points. Despite the fact that each person on the team will work these points at different speeds the team has a common estimate for the size of the work to be done. They can now use the amount of work, as measured by size, that they completed in past sprints to determine how much they are going to be able to work in their upcoming sprint. By measuring size each sprint the team can take out the variable of how long it will take each person to complete a given task and instead just focus on the size of what a team can complete in a set timeperiod, their sprint.
This approach is something that tends to be off at first but as teams get used to each other and get a better common relative size reference, estimates dramatically improve.
Fibonacci Points
To estimate teams typically will use Fibonacci points – 1, 2, 3, 5, 8, 13, etc. By using these numbers it gives better relative size between each point choice, making it easier to compare the size of things to one another. For example, using a 1-10 scale it is very hard to say whether a 6 is a lot or a little different than a 7. But with Fibonacci points it is easy to say that a 3 is roughly 50% larger than a 2 or an 8 is roughly 40% smaller than a 13.
Planning Poker
Planning poker is a common practice, especially for relatively newly formed teams. Once teams become good at point estimating they will often skip planning poker and just assign estimates out together. This proces starts by everyone getting a set of cards with Fibonacci numbers on them. A team member reads out a story to be estimated, along with acceptance criteria, then each member picks a card from their deck that they feel best represents the size of the story. Once everyone has made their selection the team compares.
If there are discrepancies the team takes the time to hear why team members feel the size they applied is justified. This is often done by looking at the highest and lowest first, then working inwards. The team must work together to arrive at a common agreement for the size of each story. Throughout this process the team can always revisit a story if the relative sizing of other stories prompt them to rethink how large a prior story was. Note that this process is often very bumpy and takes longer when teams are newly formed. The better teams know each other and the longer they have been together, the smoother the process and the better the estimates.
Happy estimating!
