Agile story points: What are they and how to use them

When you’re first starting work on an Agile team, it’ll usually take a few sprints to get into a rhythm that feels natural—especially when it comes to figuring out each team member’s capacity. A story points system will help your team to assign a numerical value or label based on perceived size or effort of an initiative, and assign a number of those stories based on what you’ve determined someone can realistically complete in a given sprint.

For example, let’s say you don’t want any one individual to take on more than 20 points total in a two-week sprint. In the beginning, there’s a real chicken and egg dilemma—if you don’t know how to properly assign points to a certain story or task, how can you decide how much is feasible to take on?

We recently asked the Think team for some advice about the straightforward methods they’ve used to size stories in Agile design and development projects. The following tips came out of a team discussion on how we’ve used various methods to size stories and efforts, both with our clients and with our agency.

What are story points?

You might be wondering: what are story points exactly? Story points are metrics (numerical values) that account for both the complexity and effort a task will take—not solely the time. For example, a low story point estimation might mean that the task is simple, straightforward, and less time-consuming than a task with a high story point estimation.

Considerations like risk, complexity, and repetition to be included in the estimation process:

• Is there a risk of dependency on stakeholders or third parties that could skew the timeline?
• Is the task difficult to complete?
• Is your team familiar and comfortable with the feature and has a leg up on the task?
• Are your designers or developers all working at the same experience level, or is there a mix of tenure and skill level on your team?

Story points vs. hours

While it can be tempting to think about story points as roughly equivalent to the hours a task or initiative is estimated to take,  story points and hours and meant to capture two slightly different things. While hours capture the projected amount of time something may take, story points capture the complex elements of completing a task that hours alone fail to capture. You may assume a task will take 2 hours to complete, for example, but a newer developer who has never used a specific tool before might take longer than a more experienced developer.

Benefits of using story points

Using story point estimation in Agile will ultimately help your team work better in a number of ways:

• You’ll become more nimble when managing sprints rather than forcing work into a rigid block of hours
• You reduce the risk of scope creep when hours ultimately fail to capture the actual time spent on complex tasks and initiatives
• You can better-plan for the unexpected—like team members getting sick and needing others to cover their work, or an unexpected technical issue that throws off the estimate for a specific task

Story points often help teams manage the inevitable complexity and uncertainty that comes with making progress on a big, long-term initiative.

How to estimate and use story points in 4 steps

At this point you may be wondering how exactly to come up with accurate story points if the idea is to capture the unclear elements of getting something done. Below are the some practical steps you can take to get started, experiment, and adjust as needed for your own team, project, and circumstances.

1. Pick a story point estimation baseline

You can start estimate story point sizes with effort or time as your base, but your team should agree on a consistent baseline and expand from there.

One useful activity to get started is to look at stories in a previous sprint in retrospective, and line up all the stories on a sliding scale based on how easy or complex the story is or was to complete. For example, you can create a baseline story that everybody can agree is a medium-level effort. Then, you can compare all future story estimates against that by going lower or higher.

Fibonacci sequence

Once you’ve ordered your stories, you can overlay a Fibonacci sequence. Anything at the far left side of the scale (or “easy”), give a “1.” Anything on the far right (more complex), give a “13” or more. Stories that were so complex that they weren’t completed or felt like they exceeded 13+ should be broken down into smaller, bite-sized chunks to increase the likelihood of successfully completing them in future sprints.

T-shirt sizing

Another approach is to try to estimate what efforts look like based on T-shirt sizes (S, M, L, XL, etc.). You can estimate what T-shirt sizes look like in days—often no less than half-day increments. So, “small” would be a half-to-full day effort, “medium” would be a one-to-two-day effort, and “large” would be a three-to-five day effort. Then, break up anything over a “large.”

Once your team is working in the sprint, they may realize that tasks and initiatives were simpler or more complex than originally thought, and you can apply that knowledge to future story point estimations.

Agile is all about continuous improvement—and making the framework work for your specific needs, not the other way around.

2. Agree on size estimates with a story point matrix

A story point matrix is a documented, agreed-upon scale or definition for how story points should be assigned to tasks on your team, for your specific initiative.

There’s no one-size-fits-all approach to story point estimations, but it’s key that the team work together to reach consensus on why stories should be sized a certain way. Everyone on the team needs to be on the same page about what sizes mean in terms of how feasible it is to complete an effort within a sprint. Rarely does any project task live in a vacuum. This helps ensure that estimations are more accurate.

Each team member brings a different perspective—for example, the design and development team needs to review what might seem like a simple design change to ensure it doesn’t impact the amount of time or even feasibility of the development process. Just because it looks like a small change on the screen doesn’t mean it’s that easy in the code. Everyone should be aligned and share expectations around the feasibility of each story being completed or handed off in the estimated amount of time.

Here are some ways your team can start coming to consensus on story point estimates:

• Identify a quantifiable task your team did (e.g. “design and build the taskbar”), and use historical data to scope out the effort for that task together.
• Take the next 5-10 features in your backlog, sort them as a team in order of biggest to smallest. Discuss why you ordered them in that way. (Oh, that one is definitely “big” because we don’t have APIs to get that data. Great! Availability of APIs can be used as one data point to evaluate the effort of future features.)
• Start to take note of and develop a common vocabulary and understanding of what makes something big vs. small, and in between. Document this criteria to reference when you’re all evaluating future features.

3. Spread out the effort for Agile projects

You can use stories to make sure that the team is sharing effort across the available bandwidth. This means that everyone should agree how much capacity they can take on, points-wise, during each sprint.

The goal in estimating is to ensure that no one is overloaded. That could look like making sure someone doesn’t get all of the high-effort or high-time stories. It’s okay if one person is always taking on an 8-point story each sprint (a larger effort that may take two weeks), while someone else takes on two 3-point stories plus a 2-point story (in which each story may take 2-3 days each). Maybe one team member has more of a design execution-type role, so they’re more likely to have 20 points each sprint, but someone in a higher-level role with more directional responsibilities may take on 5 story points each sprint.

Success here is all about 1) open communication in keeping team alignment and agreements, and 2) continuous improvement. 

4. Adapt sprints based on past story point estimates

When you start working through stories that have been estimated using the system you establish as a team, you may notice that your sizing estimations are off, or that you need to make some adjustments.

This is a good time to revisit the stories you have completed during this sprint and drop them on another sliding scale from easy to complex. Ask yourself if you’d estimate them again the same way that you did at the beginning of the sprint, knowing what you now know. If not, it’s a good time to reflect on what exactly surprised you about this story and why you’d size it differently in retrospect.

For example, some members of the team may report things like, “this one was a medium, but it took me 5 days to complete.” Try to dig into what about that story you didn’t know at the beginning, and put that into the criteria for future estimating. Remember that you won’t get it perfect every time. Story points will shift, and that’s OK.

Agile story point estimation example

Let’s say your team is working on designing and developing an employee portal for an insurance company. They’re working through their agile story estimation process for the research phase, which includes stakeholder interviews and data analysis. They’ve given the stakeholder interviews a higher numerical story point estimation than data compilation, but why? The effort of scheduling and securing time with each stakeholder makes this a higher-risk task because the team is depending on multiple outside sources and schedules. In contrast, the data analysis has a lower numerical story point estimation because it will be completed in-house by your team of experts who do this on a regular basis.

Final takeaways for understanding story points

This process is a learning experience. It can be easy for teams to get hung up on being perfectly Agile when in reality, the framework is meant to serve as a guideline to get started. If you include representatives from every department in the agile story point estimation process, think about each task as comprehensively as possible, and look back at the end result of each task to improve the accuracy in the future, you’re doing just fine. You don’t need to apply pass/fail rules for your own implementation.

Over time—if your team is working together and communicating openly during sprint cycles—the process of sizing stories will come more naturally, help your team work much more efficiently, and ensure your project stays on time and on budget.