How to use story points in Scrum?

What are story points?

Story points are simply a numeric value assigned by the team to a given user story. This value represents the amount of work required to complete the user story.

Story points quantify the work.

Story Points help you estimate and forecast the work. They give a numeric value to quantify the amount of work a user story will take to complete. The whole team assigns each story a size based on how much work it will require. 

These points guide how much work the team can take in a given sprint and when the team needs to break down a story further. The points assigned to a story are transparent to those inside and outside the team, creating a shared understanding of capacity and remaining work.

Story points focus your team.

Let’s say you’ve got five people on your team. The backlog is full, and you’re ready to begin the first sprint. So how much work do you take? 

Do we take five PBIs (Product Backlog Items), one for each of us? Some stories seem pretty big. Do we just take two? That doesn’t seem like much. How do we forecast how long it will take to get through this whole backlog?

These types of questions naturally arise in the Scrum framework, and thankfully we have tools of story points and velocity to help us answer them.

Personally, I've definitely had the bad habit of creating a daily to-do list with about a week's worth of work on it. It's not helpful. In fact, it becomes frustrating.

I've seen the same thing with teams I coach.

I've found using story points focused teams because it helped provide an objective shared measurement of how much effort work will take.

Story points are powerful because they use relative estimation.

Relative estimation strategies for story points.

You want a concrete way to measure workload. Maybe you’ve tried relative estimation but keep slipping back to using absolute sizing, such as hours.

Having led teams for years, I know how important it is to clearly and accurately measure how much work specific tasks or projects will require.

I've trained teams to use story points to estimate their work and get the workload under control.

Here are the two most common strategies for relative estimation I’ve seen work for teams.

1. The Fibonacci Sequence
2. T-shirt Sizing

Using the Fibonacci sequence for agile story point estimation.

The Fibonacci sequence is the numbers you get when you start with 1 and 2, and then each subsequent number is the sum of the previous two. So the sequence looks something like this. 

1, 2, 3, 5, 8, 13, 21, 34, 55…

This sequence helps give a sense of scale. For example, a story sized as an eight is about the same work as two stories sized as a three and a five put together. 

The Fibonacci sequence gives enough space between numbers to keep the team from being bogged down in debate and more effectively reach a consensus. It also helps them more easily compare one task with another.

As the team completes more work together, a shared work typology emerges.

Sometimes I’ve seen it help teams to use higher numbers in the Fibonacci sequence, like 55, 89, 144, 233, and 377, because there is less temptation to correlate the numbers to something absolute like hours or days.

So what does this look like in practice?

If you’re a graphic designer, it may look like assigning points like this.

• Style guide: 34 points
• Instagram series templates: 21 points
• Presentation template: 13 points

In this example, you’re saying a style guide is about as much work as a presentation template plus a series of Instagram templates.

Once you have these groups of example tasks, you can ask your team, “Is this new task more like a style guide or a presentation template?”

The Fibonacci sequence gives enough space between numbers to keep the team from being bogged down in debate and more effectively reach a consensus.

Once your team gets the hang of it, estimating is quick, and forecasting is even quicker. No more long debates about hours.

You can be confident in how much work something will take, and these numbers are very usable in calculations, making managers happy.

Using agile t-shirt sizing for story point estimation

Great teams consistently deliver quality work. And every team needs a good way to measure both the work that’s been completed and the work still to do. 

But some teams, especially non-technical teams, can struggle with some of the numerical approaches to estimating workload. 

One common contributor to this struggle is that numeric measurements can lead teams to slide back into absolute sizing rather than relative sizing. 

Using t-shirt sizes provides a concrete yet familiar scale for measuring your workload. And that’s what we’re going to cover in this post.

Having led teams for years, I know how important it is to clearly and accurately measure how much work specific tasks or projects will require.

I've trained multiple teams to use story points to estimate their work and get the workload under control.

T-shirt sizing was the perfect solution when I was rolling out Scrum across the creative department.

Story points are powerful because they use relative estimation.

I’ve also seen it applied in organizations leveraging volunteers who didn’t have as much organizational context and a wide variety of experience and expertise. 

T-shirt sizing is exactly what it sounds like. 

It uses sizes like XS, S, M, L, and XL.. to represent the relative size of different user stories. 

Similar to the Fibonacci Sequence, each size is considered the sum of the previous two. So an M is about the size of an XS and S combined.

If you want to use t-shirt sizing on your team, begin by looking at work you’ve completed in the past year. Group them by how much work/effort they required. Adjust these groups of tasks in order to apply the t-shirt size labels to them. 

Now when you encounter a new user story that needs sizing, look at the groups you’ve created and ask, “is this new task more like the tasks in the M group or the tasks in the S group?

One caution is not to tie it back to time. 

I’ve been on teams who considered a small 3 days of work, a medium was a week’s worth of work, and an L was 2 weeks. While this connection to time helped them start quickly estimating, it handicapped them from the benefits of relative sizing. 

One of the critical challenges in estimating workload is that the traditional approaches are both personal and subjective.

Even after that team had a library of sized items to compare to, it was hard for them to break away from the idea of hours, resulting in long unnecessary debates about how long work would take.

Measuring user stories in days, weeks, or hours is a common pitfall many teams struggle with.

One downside to the t-shirt sizing method being non-numeric is that you will need to convert it to numbers to calculate the team's velocity and forecast future delivery.

So you see, the t-shirt sizing method for user stories is pretty straightforward and has the benefit of referencing a familiar sizing framework. It also doesn't feel overly technical, which is good for some teams.

Once your team gets the hang of using t-shirt sizing, estimating will go quickly, and you’ll feel confident in how much work something will take.

Facilitating sizing using planning poker.

Sizing is a whole team activity, and planning poker helps get everyone involved.

Each team member has the same hand of cards, including the numbers 3, 5, 8, and 13 (or whatever sizing levels the team has decided to use). The product owner will introduce a story, and team members can ask questions if they need more clarity. 

Then they will simultaneously each play the card they feel represents the size of that story. Everyone plays the cards simultaneously so that nobody’s choice influences another.

Everyone looks at the cards and then discusses them. Let’s say someone puts down a 5, another puts down a 13, and everyone else puts down an 8. The team would ask those who put down the 5 and 13 to share why. 

Using t-shirt sizes provides a concrete yet familiar scale for measuring your workload.

Maybe the person who played the 5 has a plugin or template to help the work go much faster. Perhaps the person who played the 13 is aware of an issue the team will encounter with that story. This discussion and shared understanding are why we play planning poker.

This open discussion leverages the experience and insight of the team. After discussing the reasons for playing the cards, everyone gathers up their cards, chooses a card they think best represents the size of the user story and plays their cards simultaneously. 

If there is disagreement, they discuss it as a team. They will repeat this inspection of the stories until reaching a consensus about the size.

Story point pitfalls to avoid.

While sizing work is generally straightforward, there are some pitfalls to avoid.

Story points vs. hours

I've helped multiple teams transition to using relative sizing to measure and forecast their work.

One of the biggest pitfalls I see is using hours to estimate how much work a user story or task will take.

I want to help you avoid that pitfall.

We're used to measuring things in time. It’s how things work for a lot of our lives. And it mostly works because we’re measuring time personally. How long will this take for me to do at this time? 

When you measure work in hours rather than story points, you’re not measuring the work. You’re measuring the person.

But that question is particular to who the person is and when they’re doing the task. For absolution measurement in hours, you need to include a lot of assumptions. And that’s why teams run into so much trouble when they try to use hours to measure their shared future work. 

Let’s look at an example in everyday life. 

You need to drive somewhere. How long does it take to get there? (and for the sake of the example, pretend you can’t ask Google)

Well, the answer depends on whose driving. How heavy is their foot? And it depends on the time of day and traffic. Is it rush hour or 2 am?

This is similar to estimating how long work will take. Who's doing it? What else is happening at that time? 

But what if you used the same relative estimation approach from story points instead?

Relative estimation or relative sizing is a method of measuring new workload relative to past workload.

Is the drive you’re wondering about more like going to school, the store, or the gym?  Or is it like driving downtown? Wherever you live, you likely have an intuitive sense of how long each of those drives would be able to quickly compare some other drive relative to them.

The relative estimation approach for story points allows consistent estimation across team members and even across teams. 

When you measure work in hours rather than story points, you’re not measuring the work. You’re measuring the person. 

Measure the people rather than the work. 

Not everyone works at the same pace or has the same expertise and experience. The same task might take a junior designer the better part of a day but only take a senior designer an hour or two. So is the task a 2-hour task or an 8-hour one?

The problem with absolute sizing is you begin to measure the people, not the work. Relative sizing measures the new work against past work shared by the whole team.

Sizing in Scrum happened during the backlog refinement session; at that point, the team doesn’t know who will do the work. 

This problem can arise even when teams aren’t trying to use hours to measure their user stories. 

I’ve heard members of a team using t-shirt sizing say things like, “Well that may be a L for you but it’s only a S for me.” That comment missed the whole point of relative sizing. They’ve stumbled into the pitfall of measuring the person rather than measuring the work.

Mismanaging the discussion.

When teams are just learning Scrum, it's typical not to have many discussions when sizing tasks during backlog refinement. This situation is often because team members don’t yet feel confident in the process or just want the meeting to go quickly. 

Discussion is critical because it leverages the whole team's experience surfacing possible issues they may encounter with a given task. Or a team member may share a lesson learned from a past experience that allows this new task to be completed quicker.

Planning poker can help a team to facilitate the user story sizing discussion.

Mismanaging the discussion is a pitfall you can fall into more than just one way. I’ve seen teams do the opposite and spend forever discussing how long something should take. If you call something a M and later realize it was a S or a L, it’s ok. You can discuss and evaluate this during the retrospective session. 

Getting started with story points.

We covered a lot in this post. If you want to continue learning how to use story points and relative estimation on your team, here are some great resources:

• Learn to write user stories in Scrum
• Learn to forecast progress in Scrum
• A How-to Guide for Writing Acceptance Criteria

If you want to learn about other elements of Scrum, here are a few articles to start with. If you want a deeper dive, check out my What is Scrum? A Guide for Everyday People to Learn Scrum or my collection of Agile how-to videos on Youtube. If you have more questions, please feel free to reach out on LinkedIn.

Still not sure about your next step with Scrum? I offer a couple of free coaching sessions each month. You can signup for a free 30-minute coaching session, and we can work together to identify an excellent next step for you.