Estimation is a critical part of any project process, regardless of the methodology used. In an Agile project, where the requirements keep evolving, story point estimation assumes even greater importance. It serves as a baseline for creating project schedules, planning upcoming work and release dates, and getting all the team members on the same page at the very outset. Without a properly planned estimation process, it’s very easy for any project to get out of hand and overshoot on time, budget, and scope.
Story points are the most popular method of estimating an Agile project. In this blog, you will learn what story points are, an overview of story point estimation, ways to estimate story points along with common mistakes to avoid, how they compare to the traditional methods of estimating using hours, and user stories examples.
What are User Story Points & Why Do We Need Them?
Quite often, we find ourselves in a situation where we need to carry out a rough and ready calculation of something. Say you’ve woken up late and need to get to work on time as you have an important meeting in the morning. You could take route A, which is longer but has less traffic, or you could choose route B, where the traffic is much more but it is several miles shorter. Or there’s route C, the middle path. Factor in the day of the week, time of day, and the weather—and you have any number of variable parameters that will contribute to whether you make it to that meeting on time or not!
Agile planning is a bit like this. When you're planning is off the mark, it can lead to stretched deadlines, over-expenditure, scope creep, or the need for team members needing to move to another project because this one took too long. Improper planning can even, in extreme situations, lead to the complete breakdown of the project itself.
So, when we have so many variables to think of, which is the best method of planning? Story points, a method of relative estimation, have been proven to work well as an estimation method in Agile projects.
A story point can be defined as an abstract measure of the effort involved in fully implementing a piece of work. This could be a backlog item, a feature, or a user story. It is important to note here that there are no half measures; a story (or feature or backlog item) is said to be completed only when it is entirely done, according to the Definition of Done set by the team.
What is Story Point Estimation?
The product backlog item is usually written out in the form of a user story, which is the easiest way to describe the functionality required in that particular item.
While traditional projects define effort in terms of hours, days or weeks, in Agile this effort is measured in the form of story points. Story points are relative and not absolute, and are assigned to a story based on the complexity of the work, the effort needed to complete the work, and the risk or uncertainty involved. A story point, therefore, is an abstract measure and cannot be quantified, except in relation to another story point for another task.
User Story Estimation measures the number of story points required to complete a user story. One way to improve your understanding of User Story Point Estimation and its role in Agile management is to consider pursuing an Agile Management certification that covers this topic in-depth.
Story Points vs Hours
Traditional projects would usually base estimates on hours, days or weeks, as requirements were fixed, and schedules and budgets were rigid. There were usually no variable parameters to be kept in mind as till the end there was no change expected.
Agile, however, is all about adapting to change, and it could be expected that requirements, resources and even the end goals could change over the progress of the project. Calculation in hours will simply not work for a project which could undergo considerable transformation along the way.
Teams allocate story points to work items factoring in the amount of work involved, the complexity of the work, and the risk involved in implementing it. These are some of the reasons why story points work better for agile projects than hours:
Even when a team member is working a full 8 hours a day, there are many project-related tasks that eat into the time. Answering emails, attending meetings, and so on will take up time and cannot be avoided. So, a strict calculation using hours and dates doesn’t always work.
There is always an emotional attachment that a person has to dates. When using relative estimates, the emotional component is removed.
Every team will estimate the work based on their own parameters. For instance, a team that is composed of newbies might take longer to complete a task, while a team that has many Agile veterans will work quickly. When using story points, there is no dependency on one team member, and one person can complete a task that another has started.
Story point values are based on the relative effort of tasks, which makes it possible to assign points quickly without too much confusion.
When they work using story points, the emphasis is on solving problems based on difficulty. Team members are not rewarded for completing tasks on time but for doing them in the best possible way. This results in shipping products of greater value.
When to Estimate User Story Points
User story point estimation is generally carried out during the Product Backlog grooming event. Before each sprint, the product owner and the developers participate in a session during which the backlog items are ‘groomed,’ and the priority of tasks to be taken up is decided.
User stories are created for each task, and the team will then decide which are stories they will work on for the next sprint. Next, the team estimates each user story and arrives at the sprint backlog - the number of items they will be able to complete during the upcoming sprint.
3 Factors to Consider While Estimating Story Points
Story point estimation considers three factors:
Complexity: How difficult is it to develop this story?
Risks: Are there any dependencies on outside parties, chances of changes in the middle of a task, or any vague demands expected?
Repetition: What is the amount of work involved? Are some tasks capable of being repeated easily?
How Do We Estimate User Story Points?
There are several ways of estimating story points, and the two most common ways are by using the Fibonacci sequence, and by using the planning Poker method. Let’s understand each of these in detail.
1. Using Fibonacci sequence numbers
Fibonacci sequence numbers offer a simple scale for estimating agile story points. As we have learnt in Math, in this sequence, each number is the sum of the previous two and the series looks like this: 0, 1, 1, 2, 3, 5, 8, 13, 21, 34, 55, 89… etc.
Using this series, it becomes far easier to calculate the relative measure of two tasks. As an example, let’s assume you are holding two weights: a one-pound weight in one hand and a two-pound weight in the other. Without any problem at all, you will be able to judge the one which is heavier. However, let’s suppose you are holding a 10-pound weight in one hand and a 10.5-pound weight in the other. It’s now not as easy to judge which is heavier, is it?
When using a Fibonacci sequence, the numbers jump along the series, and we can still perceive the difference when each number is much larger than the previous one.
The team first identifies the smallest story and assigns 1 story point to it. This becomes the baseline for reference. All other stories are compared to this one, and story points are assigned to the remaining stories in line with the numbers in the Fibonacci sequence.
Along the way, a method called triangulation is used to check whether the story points assigned are roughly accurate. If an item is an 8, for example, check the items that are on either side - marked 5 and 13 - and see whether it really deserves to be labelled an 8.
2. Planning Poker
A gamified exercise called Planning Poker, carried out during the sprint planning meeting, helps team members to arrive at an understanding of the correct story point approximation for each item.
Here’s how Planning Poker works:
Each team member receives a set of cards, with numbers printed on the back.
The Product Owner brings a backlog item to the table and describes it to the team. Team members can ask questions and clarify featuresso that they arrive at a complete understanding of the work involved in developing this item.
Once the discussion is closed, each member of the team privately selects the card with the number that most accurately reflects their personal estimate of the work involved.
After all cards have been selected, the team opens their cards at the same time. The rationale behind this is that when numbers are spoken aloud, they could influence the thinking of other team members. By hiding their choice and revealing the cards together, people will think independently and discuss their choices.
They will discuss the reasons behind the highest and lowest values and might decide to hold another round of estimates to narrow down the range.
Once a consensus is met, the team will move on to the next backlog item.
If the estimates vary too much for a particular item, the leaders will discuss it further until they arrive at a consensus. In case there is any ambiguity, they could also decide to leave this item aside till more clarity is received.
Boost your career with the PMP bootcamp and become a certified project management expert. Gain the confidence to lead successful projects with our intensive training.
What are the Obvious Benefits of Using Story Points?
In a traditional project, estimates were normally based on hours, days or weeks. The requirements would be fixed at the very beginning of the project, and budgets and timelines would be pre-determined based on these rigid requirements. Even if the markets changed or industry needs to be evolved over the course of the project, these variables were not factored in till the end of the project.
Agile environments, on the other hand, are in a state of constant flux, and as the requirements themselves are volatile, time estimates in hours or days are likely to be far off the mark. However, any project needs planning in order to be successful, and an Agile project is no exception.
In order to plan budgets and schedules, Agile project managers must have a way of creating fairly accurate estimates that can be trusted. Story points are the simplest way of creating Agile estimates that can be used for making project planning decisions, and they offer very obvious benefits:
Story point estimation is very quick and easy. Even a novice can easily learn the ropes.
Even if you have not worked on a particular story in the past, since story point estimation is a collaborative effort, it becomes easy to come up with a consensus for a relative effort based on the baseline story.
There are many project-related tasks that eat into a team member’s work day, such as attending meetings, answering work-related emails or updating trackers. An estimate that is based on hours does not take these extra tasks into account, and hence usually ends up in delays. Story point estimates that are not based on hours are more likely to be accurate.
Story points are estimated based on the tasks completed in the previous sprint. The team already has a fair idea of their pace and capability, so the estimates will get more accurate over successive sprints.
When using story points, there is no time commitment involved, and this works well for a project that is constantly changing. Story points factor in the uncertainty involved, as requirements can change at any time.
Sprints can be planned easily based on story points, and this allows the team to schedule and plan releases while better managing budgets and resources.
Common Mistakes to Avoid in Story Point Estimation
Keep in mind that story points are based on the complexity of tasks, the effort needed to complete them, and the uncertainty and risk involved. Do not size the story based on only one or two of these parameters.
Many teams make the mistake of translating story points to hours. Some team members may be slower than others, and the effort needed will be different.
Do note that story points are not accurate, as Agile itself is a flexible methodology. They are only to be used as an approximate measure for planning the project.
Very small tasks need not be story-pointed. They are likely to take just a fraction of a story point and sometimes could even be completed in the time it takes to estimate them.
If the team changes midway, and the new developers are much more (or less) experienced than the ones who left, it might be a good idea to establish a new story point reference as the work context and subsequently the effort involved for the new members has changed.
Estimation is a team effort, and all team members should participate in the session. Each team member should be allowed to voice their opinion during the process.
The retrospective can be used to arrive at insights on the story point estimation that has been completed. As more sprints are completed, the team will become more accurate in their estimations.
The Last Word
As we have seen, using story points helps to keep the planning process transparent, faster and more honest. However, since it’s such an abstract measure, a story point can be a difficult concept to grasp, especially for the newbie.
During the first sprint, it can be expected that the estimation will not only take time but will also be less accurate; and this is only natural. As agile team members gain experience, they will be able to arrive at more accurate story point estimates. By laying more emphasis on the effort involved rather than the time, the team will be better organized and prepared to complete tasks on time and to the highest quality.
In an Agile world where change is the only constant—and uncertainty is the only thing that’s certain—estimating using story points is a simple and straightforward way to judge the effort needed to complete a set of tasks. While those who are new to Agile might find this hard at first, practice makes perfect, and they will soon learn from their past experiences. Over time, the team will be able to predict story points with greater accuracy and can manage backlogs with ease. KnowlegeHut's Agile Management certification could provide you with the knowledge and skills necessary to effectively estimate user story points and other project tasks using Agile methodologies.
User Story Point Estimation FAQs
1. How to use story points in Agile?
Story points in Agile can be used as below:
Introduce story points as a relative measure of task complexity, effort, and uncertainty.
Use collaborative estimation methods, like Planning Poker, to assign story points to tasks.
Track completed story points in each sprint to calculate the team's velocity.
Leverage velocity to forecast work capacity, prioritize backlog items, and set realistic expectations.
Continuously refine story point estimation and velocity calculation based on the team's experience and performance.
2. Is it mandatory to use story point estimation in scrum?
Story point estimation is not mandatory, but it's a widely used method in Scrum.
It helps teams understand task complexity, set expectations, and improve planning.
Alternatives include time-based estimation or other relative-sizing techniques.
The key is to adopt a consistent, effective estimation approach tailored to the team's needs.
Why would teams use the Fibonacci sequence for story points estimation in agile?
3. Why use story points instead of time estimates?
Story points are a more accurate way of estimating work complexity and effort compared to time estimates. They allow teams to focus on the work required instead of getting bogged down by time-related details. Story points are relative to each team's specific abilities and capabilities, allowing for more accurate estimates and a better understanding of the team's capacity. Additionally, story points help teams avoid the problem of constantly adjusting estimates based on external factors like interruptions or unforeseen problems.
4. How do you use story point estimates for project planning?
To use story points for project planning, teams first estimate the complexity and effort required for each user story. Then, they assign a numerical value to each story point, based on the team's capacity and ability. Using these values, teams can create a backlog of user stories and prioritize them based on their estimated complexity. The team can then use this prioritized backlog to plan the project and set achievable goals for each sprint or iteration.
5. How often should story point estimation be done?
Story point estimation should be done:
Prior to each sprint planning session.
Whenever new tasks are added to the backlog.
When significant changes occur in project scope or requirements.
As needed to reassess task complexity or team capacity.
Lindy Quick
Blog Author
Lindy Quick, SPCT, is a dynamic Transformation Architect and Senior Business Agility Consultant with a proven track record of success in driving agile transformations. With expertise in multiple agile frameworks, including SAFe, Scrum, and Kanban, Lindy has led impactful transformations across diverse industries such as manufacturing, defense, insurance/financial, and federal government. Lindy's exceptional communication, leadership, and problem-solving skills have earned her a reputation as a trusted advisor. Currently associated with KnowledgeHut and upGrad, Lindy fosters Lean-Agile principles and mindset through coaching, training, and successful execution of transformations. With a passion for effective value delivery, Lindy is a sought-after expert in the field.
Share This Article
Ready to Master the Skills that Drive Your Career?
Avail your free 1:1 mentorship session.
Upcoming Agile Management Batches & Dates
Name
Date
Fee
Know more
Offer
Hello! Ready to elevate your career? Explore 500+ future-ready courses with KnowledgeHut upGrad 🚀x
1
Fast forward your career with 500+ future-ready courses ⏩💻👩🎓📚x
.png&w=3840&q=75)
