What Are Story Points?
Story points are units of measurement to estimate the effort needed to complete items in the product backlog. For agile development teams, the backlog item is typically a user story. That’s why we call the unit a story point. Though the estimate could be for another type of task, such as a bug fix.
Agile teams often use the story-point method to estimate how much work they can complete during the next sprint. The team might start its backlog review with a fixed number of points—maybe 5 or 8—for the entire sprint. Next, they will look at the backlog’s higher-priority items. In turn, they will begin allocating those points to the tasks that seem most urgent or strategically valuable.
Developers work at different paces and have different technical abilities. Story points can be useful in helping teams create a shared understanding about the effort of each task.
You can think of story points as creating a common currency for limited development resources. Each team can use them toward any upcoming projects.
How Do You Estimate Them?
To estimate the number of story points for a list of tasks, a development team and product owner work together reviewing several factors, such as:
Note: In some cases, a development team will review a backlog item and estimate that it will require too many points to complete in a single sprint. In these situations, the team might decide to break the task into smaller stories.
Assign them using planning poker.
Agile teams can estimate points using different methods, but planning poker is one of the most popular.
With this approach, the team starts with a deck of cards, each with a number —1, 2, 3, 5, 8, 13, etc.—representing the Fibonacci sequence in mathematics.
Then the team reviews and discusses tasks on the backlog, one at a time, and team members use a card to represent their story-point estimate for that task. A 1 card indicates a relatively easy task. An 8 card suggests the team member believes the task will be complex, difficult, or risky—or all three.
Pro Tip: Keep in mind, each story-point estimate reflects all three of the factors above—the amount of work, complexity, and uncertainty or risk.
If the team agrees that a user story will not require much work, it might earn a 1 on the “amount of work” scale. But if the team isn’t sure about the stakeholder’s thinking behind the story, they might develop it incorrectly and need to start over. That should earn the task a higher story-point estimate on the “uncertainty” scale.
Should You Convert Story Points into Hours?
One of the most challenging parts of a developer’s job is estimating how much work a project will take. Often developers have no way of knowing how long a task will take until they’ve started working on it.
The key benefit of using story points is that they allow a development team to estimate the overall effort and difficulty, rather than committing themselves to a specific number of hours to complete it.
Also, story points can help team members—who might view a task differently in terms of hours—understand the task’s complexity or amount of work involved. As Mountain Goat Software’s Mike Cohn points out:
“Two developers can start by estimating a given user story as one point even if their estimates of the actual time on task differ. Starting with that estimate, they can then agree to estimate something as two points if each agrees it will take twice as long as the first story.”
For these reasons, agile teams should estimate their workloads using story points instead of hours.
Related Terms
user story, planning poker, Fibonacci agile estimation, product backlog, sprint planning
