Story points are an estimation technique used in Agile project management methodologies to help your team scope the effort required to complete a task. Story points account for factors like task complexity and uncertainty, which makes them more accurate than other estimation techniques such as time-based estimation. Estimating story points may sound complicated, but we’ve got you covered—we’ve broken down the process into six simple steps.
Think about the last time you went on a road trip. Did it take as long as you thought it would or did you run into unexpected time-sucks, like traffic jams? Planning and estimating projects can feel a lot like that. Unexpected obstacles and project uncertainties can delay your project timeline and lead to scope creep. And, just like on your drive, you can find yourself somewhere you never expected to be—like over-budget and underperforming.
That’s where estimation techniques come in. With estimation techniques, like story points, you can accurately scope tasks, giving you and your team a clearer picture of how much effort tasks will take and where issues might come up. Let’s dig into the benefits of story points and how to use them.
Story points are a way to estimate the amount of effort required to complete a user story in your product backlog. You’ll usually estimate story points before a sprint planning meeting, since that’s when your team determines how much work they can carry out in an upcoming sprint.
Typically, story points take into account three factors that can impact a task’s scope and effort, and the story point’s value increases accordingly. Since story points are relative, you find their value by factoring in these details and comparing similar tasks to each other.
Repetition is the team’s experience with similar tasks.
Complexity is the task’s level of difficulty (and how clear the objectives of the task are).
One important thing to know is that story points are relative—meaning that their relative value and ratios to each other are what matter, not their actual numerical value.
Mike Cohn, founder of Mountain Goat Software and author of Agile Estimating and Planning, popularized story points as part of the Agile framework.
You might be wondering, why not just use time as an estimate for tasks? And you’re not wrong: time-based (or hours) estimation is a popular way to scope work.
But there’s a downside—unlike story points, time-based estimates don’t account for complexity, risk, or uncertainty. They also depend on each team member’s personal estimation, which can vary depending on seniority, understanding of the task, and experience with similar tasks.
Story points solve these potential issues by encouraging collaboration and accounting for risk, complexity, and experience. The result is a universal scoring system that keeps team members aligned.
Now that you know what story points are, let’s go over how you can estimate them to scope user stories.
A strong understanding of story points is crucial to success. To ease your team into the process, walk them through the basics and benefits of story points. In particular, make sure they understand that the story point numbers need to scale relative to each other.
Tip: Remember, ratios matter with story points, not the actual numbers. In other words, a task assigned a story point of two should take twice as much effort as a task assigned a story point of one. A task assigned a story point of three should take one and a half the amount of effort as a task assigned a story point of two. You see where we’re going with this.
Next, determine your story point sequence. This will become the scoring method your team will use to assign story points in your estimation meeting (more on that later). Sequences are helpful because they force your team to focus on the relative size between the numbers, making estimating complex tasks easier. So, what story point sequence should you use? The Fibonacci sequence—a series of numbers where each number is the sum of the two preceding numbers—is popular for estimating in Agile. But it can get complicated. If numerical values overwhelm your team, try t-shirt sizing. As the name suggests, this sequence breaks down tasks into more manageable sizing based on t-shirt sizes: XS, S, M, L, XL, and XXL.
Tip: When estimating in Agile, teams typically change the Fibonacci sequence to 0, 0.5, 1, 2, 3, 5, 8, 13, 20, 40, 100 for ease of use.
A story point matrix is basically a fleshed-out version of your story point sequence. It serves as a baseline for your estimation meeting and gives your team a clearer idea of how to score each task. If you haven’t used story points before, we recommend using your knowledge of the tasks your team typically completes and the complexity, uncertainty, and effort associated with them.
As you can see, story point values increase as the task’s effort, complexity, and risk increases.
Tip: Your story point matrix will evolve as you run sprints and gain a better understanding of the effort associated with your team’s tasks. Don’t worry about making it perfect the first time—build off your team’s typical tasks and plan to re-evaluate the matrix after every sprint.Download free story point matrix template
Now that you’ve chosen your story point sequence and created your story point matrix, it’s time to get to the meat of the matter: estimating your story points with a planning poker meeting.
The goal of planning poker is to assign story points to user stories, get your team on the same page, and develop an idea of how many tasks your team can complete in the upcoming sprint. Planning poker does this by allowing everyone to weigh in on upcoming work. With the whole team involved, you can be sure you're assigning story points based on diverse opinions and preventing unconscious biases.
Here’s how to run a successful planning poker meeting.
Give your team a defined story point matrix for reference, as well as a set of cards that depict your story point sequence. You can create the cards yourself or download a set.
Select a user story.
Discuss the story with your team, like what’s involved and what success looks like.
Have each team member privately select the story point card they feel represents the amount of effort required to complete the story.
Have your team reveal their card selections at the same time. If the story points align, move on to the next user story. If the story points don’t align, continue to discuss the user story until you reach an agreement.
Repeat the process until you’ve assigned story points to all the tasks in your product backlog.
Using your story point matrix as a baseline, determine how many tasks your team can complete in the upcoming sprint.
Tip: Plan to hold planning poker sessions after your team has prioritized the backlog and before your sprint has kicked off. Planning poker sessions can take between two and four hours (and your first session is likely to take longer) so plan accordingly.
If it’s your first time using story points, you won’t know exactly how many story points you can complete per sprint (also known as “sprint velocity”) until you’ve completed your first full sprint. That’s okay. In your sprint planning meeting, use your best estimation of how many story points to include in your sprint based on the complexity of tasks and the story point value.
Tip: Your first sprint might include a high number of low-value story points, a low number of high-value story points, or a mix. Over time, you’ll learn what works best for your team and improve the process based on your team’s feedback.Darmowy szablon planowania sprintu
Once you’ve completed your first sprint using story points, it’s time to focus on a main theme of the Agile framework: continuous improvement. To do this, get together with your team and discuss what went well and what could improve. You can hold a separate meeting for this or include it in your sprint retrospective.
Ask your team questions like if the story points were scoped correctly, what unexpected project bottlenecks they encountered, and the other reasons targets weren’t met. Use the answers to improve the process for the next sprint. If needed, re-evaluate your story point sequence or your story point matrix.
Use your findings to estimate sprint velocity, the number of story points your team can complete in any given sprint. For example, if your team completed four story points per day, your sprint velocity is 40 story points per two-week sprint.
Tip: Once you’ve determined your team’s velocity, use that number to distribute story points and see how many sprints it will take your team to complete an entire project.
It’s no secret: planning ahead is key in project management. Failure to properly scope and schedule out work can lead to missed deadlines, scope creep, and project failure. But if that sounds scary, don’t fret. Story points can help.
To better understand story points, let’s take a look at how to use them within the Agile framework:
First, write a user story for each desired feature. User stories follow the format “As a [persona], I want to [goal], so that [result or benefit].”
Add your user stories to your product backlog.
Assign story points to each user story to estimate effort.
Use story points to select user stories from your backlog, ensuring you’re picking the right “amount” of work for each sprint.
Execute your sprint.
Let’s say your user story is “As a user, I want to be able to submit feedback and questions through the site to better understand product features.” You’d assign this user story a story point—again, the amount of effort you think is required to complete the story. You can then break down the story into smaller tasks, such as scoping and designing the feedback form, writing the code for the form, staging the page and testing the form, and publishing the page.Zarządzaj zwinnymi zespołami z Asaną
There’s a reason story points are the MVP of estimation techniques—they make estimating effort easier and simplify sprint planning. But that’s not all. Here are a few more benefits of using story points:
Drive faster planning. Story points are relative, meaning you calculate the value of one story point by comparing it to similar, already estimated points. Using a relative scoring method leads to faster estimation over time—a big win for your team.
Take unpredictability and risk into account. Story points account for elements like unpredictability and risk. Using these factors in your planning takes the guesswork out of estimating, letting you more accurately scope effort.
Remove skills bias from your planning and get your team on the same page. Relying on individual team member estimations isn't always best. After all, a senior team member will probably give a pretty different effort estimation than a junior team member. Story points prevent these issues by encouraging collaboration in the form of planning poker meetings.
Create meaningful deadlines. No one likes arbitrary deadlines, but that’s often what you get when you use other estimation techniques. Since story points are more nuanced, they result in meaningful due dates.
Build better estimations going forward. One of the major perks of story points is they’re adaptable and reusable. That means once you’ve created a story point matrix and held your first sprint, you can use your learnings to reevaluate your original story point values and develop more accurate estimations.
It’s not all easy in story point land. Story points streamline the project management process, but only if you avoid certain mistakes when estimating. Here are some common mistakes teams make when estimating story points—and how to avoid them.
Using story points that aren’t relative. The relative nature of story points makes understanding how tasks compare to each other easier for your team. That’s why you shouldn’t assign points arbitrarily. Remember: story points should scale relative to each other.
Using hours for your story points. Since time estimation doesn’t account for factors like complexity and uncertainty, using hour estimates or days as your story points is contrary to their goal. Instead, factor in the three components we’ve gone over—complexity, risk, and repetition—to determine your story point values.
Taking the average of your team’s scores when planning poker. If your team’s story point estimations don’t match up, don’t take the average of the points. Instead, open the floor and discuss the discrepancy. Once you have a better understanding of why the estimations don’t align, you can find a story point everyone agrees on.
Assigning story points to user stories that are too large. Not everything needs a story point. If a user story is so large you feel none of the story point values in your matrix account for the effort required, it may be worth breaking it down further.
Failing to clarify expectations with team members about story point values. If your team doesn’t understand story points, they’re not useful. Luckily, there’s an easy solution: talk to your team about the estimation method. Walk them through an example story point matrix and chat through each task so they accurately assign story points.
Story points are an important piece of the project management puzzle. But correctly estimating effort and getting tasks to the finish line is a lot easier when your product backlog items are well-organized and match your team’s work. Asana is here to help. Organize your backlog, track your Agile projects, and communicate with your team efficiently with a sprint planning template as collaborative as your team.Darmowy szablon planowania sprintu