Many Scrum Teams choose to formulate the items on their product backlog as stories. A “story” is a short and concise explanation of a feature written from the perspective of the user, and what they want to achieve from using that feature.
There are many ways to do estimates in a project, and a whole debate about whether or not those ways have any place in agile and Scrum. But most of the Scrum Teams that use the story format for their backlog items also estimate the effort to complete them in story points.
For everything you need to know about what story points are, how they work, and how to use them, read on below.
What Are Story Points?
Story points are a unit of measurement for estimating the effort required to complete a work item on the backlog. They are a number that the Developers on the Scrum Team come up with and agree on during the Backlog Refinement or Sprint Planning event.
The Scrum Master can facilitate the process, and the Product Owner can provide the inputs needed, but it’s the Developers—the members of the team accountable for completing the work—who perform and decide on the estimation.
There’s no strict definition of story points, and a Scrum Team that estimates its work in story points can use any number or pattern. Most teams choose to follow the Fibonacci sequence (0, 1, 1, 2, 3, 5, 8, 13, 21, etc.).
Making Story Points Work for You
The key to mastering effort estimation with story points is to understand that, as a unit of measurement, story points are relative and approximate.
Story points are relative because the Developers on a Scrum Team can only estimate based on what they know and their experience from having done similar work in the past.
Story points are approximate because they are estimates; they can’t account for what the Developers don’t know and the changes that will happen throughout the progression of the sprint.
In other words, story points are an intentionally imperfect measure because they are used to express a subjective prediction about the difficulty of getting a job done in the future. (And predictions, as recent years have taught us, can only be so accurate.)
How to Use Story Points
Suppose you and I were the Developers on a Scrum Team building a computer game, and we just finished estimating the effort for three stories related to user registration and login.
That part of our backlog would look like this:
|#||User Story||Story Points|
|1||As a first-time user of the game, I want to sign up with my email address so I can start playing.||3|
|2||As a first-time user of the game, I want to sign up with my Google account so I can start playing.||5|
|3||As a first-time user of the game, I want to sign up with my Facebook account so I can start playing.||8|
We got to these estimates through a discussion.
Both of us proposed 3 story points for user story #1 because we’ve built email-based registration and login before and, even though we haven’t done it in this project, we nevertheless know exactly what to do and the mistakes to watch out for.
At first, I proposed 8 story points for user story #5 because I’d never worked on single sign-on with Google and I’m not familiar with their APIs. But you talked me into agreeing on 5 because you have, and you agreed to show me the ropes at the beginning of the sprint so I can work on them and learn.
Neither of us had worked on single sign-on with Facebook, so we’re not familiar with their APIs. But both of us know from previous experiences that these APIs are not necessarily well-documented. So after a discussion about whether to assign a value of 8 or 11 to story #3, we agreed to estimate 8 story points for it because we still have some experience with SSO and Facebook.
As we did this, we discussed a few things with the Product Owner to gauge the complexity of the implementation and to make sure that nothing important was missed in the formulation of the stories and the acceptance criteria for each.
The Scrum Master coached us with some guiding questions, like “Do you guys have similar, or at least somewhat related, experiences from the past that you can use as a baseline for this?”, facilitating the estimation.
What Is Velocity?
Velocity is a metric for the total amount of work that the Scrum Team has completed in a given sprint. Teams that estimate their work items in story points also measure their velocity in story points.
|Sprint 1||11 story points|
|Sprint 2||17 story points|
|Sprint 3||17 story points|
|Sprint 4||22 story points|
|Sprint 5||17 story points|
|Average||16.8 story points|
Average velocity is the average amount of work that the Scrum Team has completed in any given number of sprints. In the example table above, the average velocity of the team is 16.8 story points (which can be rounded up to 17 story points).
When planning the sprint backlog during the Sprint Pllanning event, it is a good practice to make sure that the total number of planned story points does not exceed the velocity of the last sprint or the average velocity of the last few sprints.
Otherwise, there’s a risk that the team will take on too much and deliver too little—and have to deal with the internal challenges and external pressures of having done so.