How to use story points in Agile

What are story points in Agile?

In Agile project management, story points are units of measurement that teams can use to estimate the time and effort necessary to complete various tasks.

Story points enable a system of time estimation that works on a relative basis. This means that, rather than predicting how long a task might take in terms of total hours, days or weeks, teams use story points to compare one task's estimated completion time to another.

For example, the team might assign four story points to one product backlog item, such as a user story involving the implementation of a simple new feature. Meanwhile, another item might receive eight story points because the team anticipates that it will take twice as long to complete and require twice as much effort as the four-point user story.

Using story points, teams can break sprints -- meaning fixed periods of time, typically between one to four weeks, that they spend working on a project -- into smaller units of work and estimate the time and effort that each one will require relative to the overall sprint.

Story points vs. time estimates

Teams don't strictly need story points to practice Scrum or other popular Agile methodologies. An alternative approach is to plan sprints using direct time estimates. Teams might allocate two days to complete one user story and four days for another.

Time estimates can work well in scenarios where the following conditions are met:

• All software development team members can work at approximately the same pace, meaning one engineer is able to complete a given task in the same amount of time as any other.
• Work items are well understood before work is underway, making it easy to predict accurately exactly how long a task will take.
• Few risks and uncertainties, such as an unexpected server failure that could disrupt workflows, threaten to delay work item completion.

Most development projects, however, are rarely this consistent, predictable and low risk. It's much more common for teams to include engineers of varying levels of experience, meaning not all of them can work at the same pace. In addition, the exact time and effort required to complete a task are often difficult to predict with a high degree of accuracy because engineers don't know exactly how hard or time-consuming something will be until they begin working on it.

Story points offer the advantage of enabling teams to think of value creation in terms of the effort invested in a task rather than the total hours spent on it.

Benefits of using story points in Agile

It's virtually impossible to avoid the various risks and uncertainties that could derail projects. This is why a story point is often a superior unit of measurement for time and effort rather than using plain time estimation techniques. The relative nature of story points means that teams aren't bound to complete a task within a set period of time -- nor are they at risk of feeling like they've failed or fallen behind when they miss a target defined in terms of hours or days.

In addition, story points offer the advantage of enabling teams to think of value creation in terms of the effort invested in a task rather than the total hours spent on it. In this way, story points encourage engineers to work innovatively and efficiently to complete complex tasks. They also discourage the unproductive practice of artificially "stretching out" work to fit the number of hours assigned to it when a task could be completed sooner.

How to use story points in Agile

The best way to implement story points -- whether for a brand-new project or for an existing project that is currently using a different time estimation method -- is to break the process into five basic steps.

1. Educate the team about story points

First, ensure that everyone on the team is on board with story points. This is especially important for projects that are transitioning to story points from a different method or those where engineers haven't previously used story points.

To gain buy-in, project managers should educate stakeholders on how story points work and which benefits they offer over alternative methods.

2. Establish a story point sequence

Before they can assign story points to tasks, teams should establish acceptable story point values. This is important because story points work best when there is a specific set of numbers that teams can use when assigning story points to a task. Otherwise, they could end up assigning overly specific story point values, such as 2.8 or 9.35. This undercuts the value of using story points in the first place because it generates rigid estimations that are not likely to be accurate.

A common approach for establishing a set of acceptable point values is to use a fixed sequence of numbers, such as the Fibonacci sequence, in which each additional number is equal to the sum of the numbers preceding it -- 1, 2, 3, 5, 8, 13, 21 and so on.

3. Build a story point matrix

A story point matrix describes, in basic terms, the types of tasks and scope of work that the team should associate with story point values. For example, a basic story point matrix for values derived from the Fibonacci sequence might look like this:

4. Estimate story points for a sprint

With a story point matrix complete, the team is ready to begin assigning story points to specific work items.

A popular way of doing this is to conduct a planning poker meeting, in which engineers use cards to estimate the time, effort and risk associated with each task. In a typical planning poker meeting, participants discuss each user story one by one. Then, each attendee selects a card that represents how many story points they think the story should receive.

If all or most of the cards match, the team has achieved consensus and can settle on the number of story points for the task. Otherwise, they go back to the discussion stage, where attendees can share more insights on why they think the task should receive a higher or lower point value before selecting cards again. The team repeats this process until it achieves a shared understanding and then works through other user stories in the same way.

5. Track and improve story point estimation

The final step in the Agile story point implementation process is to monitor how accurately story point estimates reflect the actual levels of time, effort and risk. After the team completes each sprint, it should review this data and then use the insights it gleans to improve story point estimates for the next sprint.

For example, the data may show that the team significantly underestimated the appropriate story point value for a certain type of user story. When a similar user story appears, engineers can avoid making the mistake again.

Chris Tozzi is a freelance writer, research adviser, and professor of IT and society. He has previously worked as a journalist and Linux systems administrator.