How awesome would it be if development teams could just look at a user story and immediately provide a definitive figure of how long it would take to complete it?
That would be pretty cool, right? Everything else, from sprint planning to budget estimates and feature releases, would run smoothly.
Unfortunately, effort estimation in the product development world is way more complicated than that. You can never really be 100% accurate with your estimates. Risks and unexpected complexities can all affect the scope and timeline of each task.
That said, several techniques can help you better predict the effort required to complete each task. Using story points is one of them.
This guide will help you understand what story points are in agile development and why they are important. Here is everything you’re going to learn:
- What are story points?
- What is story points estimation?
- 6 steps to estimate story points
- Story points vs hours – why we use hours for agile estimation
By the end of this review, you should be able to identify the right method of agile estimation based on your unique needs.
🚀 We’d love to learn more about your team and the challenges in your current workflow. Let’s chat!
What Are Story Points?
Story points in agile product development are metrics used for estimating how much effort it would take to complete a user story from a sprint backlog.
Story points are usually more abstract than hours. However, the number does take into account three key factors (we’ll discuss them in the next section) that affect the effort or amount of time it takes to complete a user story. Therefore, this agile estimation method can be considered to be quite comprehensive.
Unfortunately, it also has a dark side. For one, it’s not the most precise method of effort estimation. Moreover, the abstract nature of this technique can cause friction and confusion among some stakeholders.
Most businesses are used to specific numbers like hours. Therefore, using and mentioning story points might push your clients too far out of their comfort zones. Story points may sound too complex a concept to them.
We’ll discuss more pros and cons of story points later on.
Keep in mind that story points estimation usually takes place before the sprint planning meeting. Let’s now take a closer look at how it works.
What Is Story Points Estimation?
Story point estimation simply means establishing how much effort and complexity a user story presents and assigning it a relative value.
To do this, each user story is gauged against three main factors. These are:
- Risk: The amount of the total risk associated with a story will influence the effort and time required to complete it. This could include technical, business, or external factors. For example, dependencies on other stakeholders and vague client demands can increase the risk for a particular user story.
- Complexity: The degree of difficulty for a story, including technical challenges and the level of understanding required to complete it.
- Repetition: Repetition looks at how familiar the team members are with the user story or task. Have they ever handled a similar user story before? Repetition may also look at monotonous subtasks within the user story.
Once incorporated, these factors help provide a more comprehensive understanding of the effort and complexity required to complete a story. This, in turn, helps you prioritize tasks and plan your sprints more accurately.
6 Steps to Estimate Story Points
Here are six simple steps to help you estimate story points accurately:
1. Determine a Baseline for Each Story Line
Start with a user story that the team is familiar with, and determine its level of effort and complexity as a baseline for future estimations. This can serve as a base story (also called a reference story) for the team to compare against when estimating future stories.
You can choose the smallest and least complex user story and set it as 1 story point. This is your baseline. Then, use this baseline to measure the effort and complexity of other stories and assign them their respective story point values (with respect to your baseline).
2. Follow Fibonacci Sequence Numbers
Another common approach is to use the Fibonacci sequence numbers (1, 1, 2, 3, 5, 8, 13…) as story point values. This sequence is a series of numbers where each number is the sum of the previous two numbers, starting with 1.
So, for example, in the sequence 1, 1,2,3,5,8,13, the number 3 comes from 2+1. Meanwhile, the number 5 comes from 3+2. You get the idea.
But in agile development, the Fibonacci sequence is usually modified to start from 0.5. So the sequence will be 0.5, 1, 2, 3, 5, 8, 13.
Using the Fibonacci sequence to estimate story points helps your team estimate complex stories more easily. That’s because the difference between two story points is usually more pronounced.
For example, imagine your team has to develop a new widget for an app. Everybody knows it’s going to be a relatively complex and time-consuming task.
Let’s say you’re using a linear scale of 1-30 to estimate your story points. How will the team agree on whether to assign this story a 26 or a 27? What about 28? Your team members can come with different yet close numbers causing unnecessary confusion.
But with the Fibonacci sequence, it’s easier for your entire team to agree on a story point value. They may assign it a 13 or an 8, but there won’t be as much debate about whether it should be a 26 or 27, right?
3. Build A Story Point Estimation Matrix
Remember the base user story you identified in step one? You’ll need to use it as story point 1 and make it the baseline of your story point estimation matrix. Then, using the Fibonacci numbers you’ve created above, start scoring your user stories accordingly.
So, for example, if it’s a slightly more complex user story, you’ll give it a story point of 2. You can give it a higher score if it’s way more complicated than the base storyline. We’ll show you how your team can come up with these scores in the next step.
With that said, we’ll advise you to put a cap on your Fibonacci scores. For example, our team can give story points of up to 13. This is critical in preventing scope creep. Think about it. If a task is too complex to warrant a score higher than 13, the team should surely split it into subtasks. These can then be handled in multiple sprints.
Similarly, if a task is too easy (so it scored 0.5), your team should consider adding it to another user story. That should boost team efficiency.
4. Poker Planning
Also known as Planning Poker, this approach involves the team playing a game of cards to estimate story points. Each member has a deck of cards with Fibonacci sequence numbers, and they hold up a card to show their estimation for a specific user story.
If all the individual estimates are the same, the product backlog item is assigned that value, and the team moves on to other user stories from the backlog to continue the backlog grooming process.
However, if the individual estimates vary, the team then discusses and agrees on the story’s estimation. This approach can help encourage discussion and collaboration within the team, as well as provide a fun and interactive way to estimate story points.
Another incredible benefit of Planning Poker is it eliminates unconscious bias. Team members usually pick a number in secret then the whole squad reveals their picks at the same time.
5. Track Your Sprint Velocity
Your team’s sprint velocity is the total number of story points completed within a sprint. By tracking this metric over time, you can better understand your team’s capacity for completing user stories. You can then use it as a guide for estimating future stories in terms of both effort and complexity.
For example, let’s say that in the last three sprints, your team’s average velocity was 20 story points per sprint. This can serve as a guideline for your team when estimating future stories, as they know that their capacity for completing user stories is around 20 points per sprint.
You’ll find Tara’s smart sprint planning software super resourceful here. Our platform analyzes your previous sprints to give you accurate effort estimates of your team. It also makes sprint scoping a simple task. You’ll receive alerts every time the platform detects a sprint overload.
Tara lets you track team velocity in story points or hours. Our team uses hours. We’ll tell you why in a moment. Let’s first go through the last step of estimating story points in agile.
6. Use Past Estimations to Improve Your Story Points
One of the best ways to improve your story point estimations is to review past sprints and analyze the accuracy of your team’s estimations. Did they underestimate or overestimate certain user stories? Why did this happen, and what can the team do in future sprints to avoid similar issues with estimation?
An example would be if the team consistently underestimates the effort and complexity of user stories related to a certain feature or technology. In this case, the team can make a note to add an extra buffer when estimating future stories involving that feature or technology.
By continuously reflecting on past sprints and adjusting your story point estimates accordingly, you can improve the accuracy and effectiveness of your agile planning. You can also re-evaluate and re-adjust your chosen sequence and baseline story for better estimation.
Story Points vs. Hours – Why We Use Hours for Agile Estimation
When it comes to agile estimation, there are two popular options: story points and hours/days. Both have their own benefits and drawbacks, so it can be difficult to decide which is the better option for your team.
Here are the pros and cons of both to help you make an informed decision.
Pros and Cons of Story Points
One of the greatest benefits of using story points in agile development is that they are easier to estimate. Instead of trying to predict exactly how many hours a specific task will take, the team can simply assign it a value based on their understanding of effort and complexity.
However, one drawback of using story points is that they are not very accurate. This is one of the biggest reasons we prefer using hours over story points.
Story points can also be confusing. What one team might estimate as a 13, another team could estimate as an 8.
Also, when given a story point, you can’t tell how much time that specific user story would need to be implemented. Consequently, this can make it harder to allot time accurately and track project progress.
If you decide to use story points, we’d like to advise you against calculating your team’s average story points to settle disagreements. Instead, open the floor for a discussion if every team member comes up with a different figure after a planning poker session. Understand everyone’s reasoning, then let the team come up with a reasonable score.
Pros and Cons of Hours/Days
When estimating effort in hours or days, you are dealing with an absolute measure of time instead of a relative measure like story points. This makes this approach more reliable, and that’s why we love it. It eliminates the potential for bias or inconsistency in estimation.
Everyone clearly understands what a certain number of hours or days means in terms of the time required to complete a task.
Another reason that makes the hours/days approach better is that it gives a clearer idea of when tasks will be completed. This can help with sprint planning and agile project management. Moreover, it allows you to track project progress more accurately.
It’s not all glamorous with this estimation technique, though. One notable downside is that it can often be challenging to predict the amount of time a specific task will take. This can lead to incorrect estimations and throw off project planning and scheduling. That’s why we find it reasonable for a new/junior team to use the story points method (because it’s simpler).
Ultimately, it’s up to your team and what works best for them in terms of agile estimation. Both story points and hours/days have their own advantages and drawbacks. Experimenting with both options may help you find the right fit for your team.
What’s more important is that your chosen estimation method helps improve overall productivity and planning in your agile development process.
In Closing
No matter which estimation method your team uses, it’s important to remember that agile planning is a dynamic process. It requires constant communication between team members and flexibility in adapting to changing project needs and priorities.
By regularly reviewing past sprints and adjusting story point estimates accordingly, your team can continuously improve the accuracy and effectiveness of your agile planning process. This, in turn, can lead to better project productivity and success.
Get started with Tara AI today – for free!