Decoding Story Points in Agile Estimation

Have you ever taken a road trip and found it didn’t go as smoothly as you anticipated? Unexpected delays, such as traffic jams, can throw off your estimated travel time. Similarly, when it comes to project planning and estimation, unforeseen obstacles and uncertainties can disrupt your timeline and expand the project’s scope beyond expectations. This can result in going over budget and underdelivering, just like ending up in an unforeseen location during your drive.

To tackle these challenges, estimation techniques like story points become invaluable. By employing story points, you gain the ability to accurately assess the scope of tasks, providing you and your team with a clearer understanding of the effort required and potential problem areas. In this article, we will delve into the advantages of story points and how to effectively utilise them for project success.

Page Contents

What Are Story Points?

Story points serve as a method to estimate the effort required for completing a user story within your product backlog. Typically, these estimates are determined before a sprint planning meeting, as that’s when your team decides how much work they can take on during the upcoming sprint. Story points consider three critical factors that influence a task’s scope and effort, leading to an appropriate increase in their value.

These points are relative in nature, meaning their value is derived by comparing similar tasks to each other and taking the following factors into account:

Risk: This factor gauges the level of uncertainty associated with a task. For instance, if a task involves third parties, contractors, or project stakeholders, it may increase the overall risk.
Repetition: The team’s prior experience with similar tasks plays a role in estimation. Tasks that the team has encountered before might be easier to estimate.
Complexity: This factor reflects the level of difficulty of a task and how well-defined its objectives are. Complex tasks may require higher story points.

It’s important to note that story points are relative, which means their numerical value isn’t as crucial as their comparative value and ratios to each other. By considering these factors and their relative importance, teams can make more accurate estimations and plan their sprints effectively.

What Impacts Story Size?

In our discussion, we covered the concept of assigning user stories based on the effort required for implementing the backlog item. Now, let’s delve into what exactly we mean by “effort.”

The Amount of Work

Each backlog item is unique, and the effort required to complete them can vary significantly. For instance, let’s consider two different backlog items:

“I want a new weapon for the main hero, Monkey King.”
“I want new weapons for all heroes.”

It’s evident that the second story would require more time and effort to implement compared to the first one. Consequently, the second story would be assigned more story points, reflecting its larger size and complexity in comparison to the relatively less demanding first story.

The Amount of Risk

In every project, there are inherent risks and uncertainties, particularly with specific types of backlog items. For instance, when a product backlog item entails working with a new framework that your team lacks substantial experience in, the risk factor associated with it will elevate the story point value.

The Complexity of The Task

Complexity plays a crucial role in any Agile estimating technique. Let’s take a look at two similar stories that differ in their acceptance criteria:

“I want a new costume for the character Geralt.”
“I want a new special attack for Geralt.”

As you can observe, the complexity varies significantly between these two stories. The first story seems relatively straightforward, involving minor tweaks to the character’s appearance. On the other hand, the second story requires coding a completely new special attack, testing it thoroughly for potential bugs, and ensuring its seamless integration into the game.

Considering the effort estimation process, it becomes evident that such user stories with higher complexity warrant more story points, reflecting the additional time and resources required to fulfil them.

Story Points vs Time-Based Estimation

You might be wondering why not simply rely on time-based estimates for tasks? Indeed, time-based (or hours) estimation is a common approach to assessing work scope. However, there is a downside to this method – unlike story points, time-based estimates fail to consider essential factors like complexity, risk, and uncertainty. Moreover, these estimates rely on the individual judgments of team members, which can vary based on their seniority, understanding of the task, and prior experience with similar assignments.

Story points offer a solution to these potential issues by promoting collaboration and factoring in risk, complexity, and experience. The outcome is a universal scoring system that keeps all team members on the same page, fostering better alignment and a more accurate representation of effort across the project.

Why Should I Use Story Points?

Story points stand out as the MVP among estimation techniques, streamlining the process of estimating effort and simplifying sprint planning. Yet, their benefits extend beyond just that; here are several more advantages of using story points:

Drive faster planning: Story points’ relative nature allows you to calculate the value of one point by comparing it to already estimated points. This relative scoring approach leads to faster estimation over time, a significant advantage for your team’s productivity.
Take unpredictability and risk into account: Story points incorporate elements like unpredictability and risk into the planning process. By considering these factors, you can eliminate guesswork and achieve more accurate effort scoping.
Remove skills bias from planning and foster team alignment: Relying solely on individual team member estimations may not yield the best results, as senior and junior team members may differ in their assessments. Story points mitigate such issues by promoting collaboration through planning poker meetings.
Create meaningful deadlines: Unlike other estimation techniques that often result in arbitrary deadlines, story points offer a more nuanced approach, leading to the establishment of more meaningful and achievable due dates.
Build better estimations for the future: A significant perk of story points lies in their adaptability and reusability. Once you’ve established a story point matrix and completed your first sprint, you can use the insights gained to reevaluate your original story point values and develop more accurate estimations going forward.

Overall, story points prove to be a versatile and valuable tool, enabling teams to make informed decisions, enhance collaboration, and continually improve their estimation process.

Disadvantages of Story Points

Story points can sometimes be unclear, especially for clients, making it challenging for them to grasp their benefits. Clients often favour time estimations because it’s a concept they can readily relate to and understand. In an attempt to bridge this gap, some teams resort to mapping story points to hours.

For example, they might equate two story points to a task that will take approximately 2-4 hours, and three story points to tasks ranging from 4 to 8 hours, and so on. This hybrid approach to task estimations is generally not recommended, but it can make it easier for clients to comprehend the use of Fibonacci numbers for task estimations.

What is Fibonacci Estimation?

Agile estimation is a method used to quantify the effort required for completing development tasks in Agile teams. Story points serve as the unit of measurement to score these tasks, where a higher point value signifies a greater perceived effort by the team.

One widely adopted scoring scale for story points is the Fibonacci sequence, where each number is the sum of the previous two in the series. The sequence goes as follows: 0, 1, 1, 2, 3, 5, 8, 13, 21, 34, 55, 89, and so on. When Agile teams employ this sequence as the scoring scale for estimating task effort, it is referred to as “Fibonacci Agile estimation.”

Why Should I Use Fibonacci Estimation for Story Pointing?

Agile consultant Mike Cohn offers a helpful metaphor to illustrate the effectiveness of the Fibonacci sequence in estimating story points. He suggests imagining holding a one-kilogramme weight (2.2 pounds) in one hand and a two-kilogramme weight (4.4 pounds) in the other. It’s easy to tell that one weight is twice as heavy as the other without looking. However, if the weights were 20kg and 21kg, the difference in weight becomes more challenging to perceive. Even though the difference remains one kilogramme in both cases, as we enter the 20kg territory (45 pounds), our brains require a greater gap between weights for clear differentiation.

This is precisely why Cohn advocates for using the Fibonacci sequence in agile story point estimation. The numbers available for selection in the sequence take larger jumps as it progresses, yet they grow at a consistent rate of approximately 60% from one number to the next. This steady increment allows our brains to perceive the differences accurately, even as the numbers become considerably larger. By employing the Fibonacci sequence, agile teams can ensure more effective and reliable estimations, enabling better planning and decision-making throughout their projects.

How Do I Use Story Points In Agile?

In project management, effective planning is crucial to success. Properly scoping and scheduling work prevents missed deadlines, scope creep, and project failure. If the prospect of these challenges sounds daunting, don’t worry. Story points offer a valuable solution. To gain a better understanding of story points and their role in the Agile framework, let’s explore how to use them:

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 the product backlog and assign story points to each one to estimate the effort required.
Use story points to select user stories from the backlog, ensuring you choose an appropriate amount of work for each sprint.
Execute your sprint. For instance, let’s consider the user story: “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 specific story point value, representing the effort you believe it will take to complete the task.
Break down the user story into smaller tasks, such as scoping and designing the feedback form, writing the code for the form, staging the page, testing the form, and finally, publishing the page.

By implementing story points in this manner, you gain a more organised and manageable approach to project planning, helping you navigate your Agile sprints with greater efficiency and confidence.

You can learn more about creating user stories in our in-depth guide here.

How Do I Start Using Story Points With My Team?

It’s important to thoroughly introduce your team to story pointing

Having grasped the concept of story points, let’s now delve into the process of estimating them to effectively scope user stories.

1. Introduce Story Points

A solid grasp of story points is pivotal for achieving success. To facilitate your team’s transition into this process, guide them through the fundamentals and advantages of using story points. It’s crucial to emphasise that the story point numbers must scale relative to each other.

Tip: Keep in mind that the ratios between story points matter more than the actual numerical values. In essence, a task assigned two story points should require twice as much effort as a task assigned one story point. Similarly, a task with three story points should demand one and a half times the effort of a task with two story points. By understanding this principle, your team can navigate the story point estimation process more effectively.

You can learn more about how to introduce your team to agile development methodologies here.

2. Determine Your Story Point Sequence

Next, it’s essential to establish your story point sequence, which will serve as the scoring method for assigning story points during your estimation meeting (more on that later). Sequences prove advantageous because they prompt your team to focus on the relative sizes between the numbers, simplifying the estimation of complex tasks. Now, which story point sequence should you adopt?

The Fibonacci sequence, a series of numbers where each number equals the sum of the two preceding ones, is widely popular for Agile estimation. However, it can be intricate to work with. If numerical values prove overwhelming for your team, consider using t-shirt sizing. As the name suggests, this sequence categorises tasks into more manageable sizes based on t-shirt labels: XS, S, M, L, XL, and XXL.

3. Create a Martix

A story point matrix serves as a comprehensive expansion of your story point sequence, providing a foundational reference for your estimation meeting and offering your team a clearer framework for scoring each task. If your team is new to story points, we recommend utilising your knowledge of the tasks they typically handle, considering factors such as complexity, uncertainty, and effort associated with those tasks.

4. Use Planning Poker To Estimate

With your story point sequence and story point matrix in place, it’s time to dive into the heart of the matter: estimating story points through a planning poker meeting. The objective of planning poker is to assign story points to user stories, foster team alignment, and gain insights into how many tasks your team can accomplish in the upcoming sprint. Planning poker achieves this by involving everyone in the decision-making process, ensuring a diverse range of opinions and mitigating unconscious biases. Here’s how to conduct a successful planning poker meeting:

Provide your team with a defined story point matrix for reference and a set of cards representing your story point sequence. These cards can be either created by you or downloaded from available sets.

Select a user story and thoroughly discuss its details with your team, including the tasks involved and the desired outcomes. Each team member privately chooses a story point card that they believe reflects the effort required to complete the story.

Simultaneously, reveal the card selections of all team members. If the story points align, move on to the next user story. However, if there is disagreement, continue discussing the user story until a consensus is reached.

Repeat the process until all tasks in your product backlog have been assigned story points. Utilizing your story point matrix as a baseline, determine the number of tasks your team can realistically complete in the upcoming sprint.

5. Plan Your Sprint

If you’re new to using story points, determining your sprint velocity (the number of story points your team can complete per sprint) will require completing your first full sprint. Don’t worry if you don’t have a precise value initially. During your sprint planning meeting, make your best estimate for how many story points to include based on the complexity of tasks and their corresponding story point values.

6. Iterate

After completing your first sprint using story points, shift your focus to a core principle of the Agile framework: continuous improvement. Gather your team and engage in a discussion to evaluate what went well and identify areas for improvement. You can hold a dedicated meeting for this purpose or include it as part of your sprint retrospective. Encourage your team to provide feedback on whether the story points were appropriately scoped, any unexpected bottlenecks they encountered during the project, and other reasons why targets may not have been met. Utilize their input to enhance the process for the next sprint.

If necessary, take the opportunity to re-evaluate your story point sequence or story point matrix based on the feedback received. Utilize the insights gained to estimate your sprint velocity—the number of story points your team can accomplish in a given sprint. For example, if your team completed four-story points per day, your sprint velocity would be 40 story points for a two-week sprint.

5 Pitfalls To Avoid When Using Story Points

While story points can greatly streamline the project management process, navigating the land of story points isn’t entirely straightforward. Certain pitfalls can arise during the estimation process, hindering its effectiveness. Here are some common mistakes teams often make when estimating story points, along with strategies to avoid them.

Abstracting Story Points

The relative nature of story points simplifies the task comparison process for your team. Consequently, it’s essential to avoid assigning points arbitrarily. Always bear in mind that story points should be scaled in relation to each other, ensuring accurate estimations and effective planning.

Using Time-Based Story Points

Time estimation, relying on hour estimates or days, falls short of addressing crucial factors such as complexity and uncertainty, which are central to the goal of story points. Instead, embrace a more comprehensive approach by considering the three key components we’ve discussed: complexity, risk, and repetition. By factoring in these elements, you can accurately determine the appropriate values for your story points, leading to more robust and effective estimations.

Averaging Your Team’s Poker Scores

In the event that your team’s story point estimations do not align, avoid simply taking the average of the points. Instead, foster open communication and encourage a discussion about the discrepancies. By exploring the reasons behind the differing estimations, you can gain a better understanding of each team member’s perspective. This open dialogue will ultimately lead to finding a consensus and arriving at a story point value that everyone agrees upon.

Creating Too-Large Stories

Not every task necessarily requires a story point. If a user story appears to be exceptionally large, to the extent that none of the story point values in your matrix adequately represent the effort involved, consider the option of breaking it down into smaller, more manageable parts. This approach can help ensure that the estimations are more accurate and aligned with the team’s capabilities.

Not Clarifying The Purpose Of Story Points

For story points to be truly beneficial, it is crucial that your team comprehends their significance. Fortunately, there is a straightforward remedy for this situation: communicate with your team about the estimation method. Take the time to discuss an example story point matrix, and go through each task with them to ensure they fully grasp the process, enabling them to assign story points accurately. By fostering open communication and understanding, your team will be better equipped to utilise story points effectively in their project estimation.

How Many Points Should Be Assigned Per Sprint?

Team capacity represents the amount of work the team can accomplish during a sprint. This value is utilised for both hour estimates and story points, serving as a critical factor in determining the team’s capabilities and planning their workload effectively.

Time-Based Estimates

When it comes to hour estimates, several considerations come into play to accurately gauge the team’s capacity:

Full-time or Part-time Involvement: Assess whether the developer is working full-time or part-time on the project, as this affects their available working hours.
Sprint Duration: Determine the duration of the sprint to calculate the total working hours available.
Sprint Ceremonies and Other Meetings: Account for the time dedicated to sprint ceremonies (daily standup, retrospective, review, planning, refinement, and demo) and any additional meetings outside the project that may impact the available work hours.
Holidays and Days Off: Consider any planned holidays or days off for the developer during the sprint.
Hotfixes and Production Issues: Decide if time needs to be allocated for handling hotfixes or urgent production-related tasks during the sprint.

This approach can also be used to estimate the project’s delivery date. By having rough estimations of all the features to be delivered and using the team’s time capacity, you can provide a possible deadline for the project. Taking these considerations into account ensures a more accurate assessment of the team’s capabilities and enables effective planning for project deadlines and task allocation.

Story Points

Story point estimations share similarities with hour estimates as they also rely on team capacity considerations. Developers must gauge how much work they can complete in one sprint, which might involve tackling a larger task along with a few smaller ones. To build a reliable time capacity, a good practice is to initially take on fewer tasks in a sprint, allowing room to add new tasks from the backlog comfortably. As the team gains familiarity with the project over two or three sprints, their estimations become more refined, increasing the likelihood of successful sprint delivery.

When it comes to estimating project deadlines using story points, the process remains similar. By assessing the remaining features to be delivered and comparing the story points with the entire team’s capacity, you can derive an estimate for the delivery date. To enhance the accuracy of this deadline estimation, consider breaking down features into smaller tasks, each having as few story points as possible. This approach provides a more precise projection of the project’s completion date, supporting effective planning and execution.

Why Does Actual Time and Estimated Time Vary So Much?

As mentioned earlier, a critical distinction between time and story points estimation lies in the responsibility for estimations. While developers handle estimations in time-based approaches, the entire team is involved in story points estimation.

Consider these scenarios:

Have you ever been ill but still willing to work?
Engaged in a disagreement with your family or spouse?
Struggled with a lack of sleep?

These situations can significantly impact your work efficiency. Even if a developer intends to find a solution, they might draw a blank at that very moment, with time ticking away. This can lead to frustration and ultimately result in lower code quality and the introduction of bugs, simply because the developer feels the pressure to complete the task within the set time limit and deliver as promised.

An interesting paradox to highlight is that tasks almost never finish before the time limit; they are typically completed exactly on time or later. This adds to the challenges faced by developers when relying solely on time-based estimations. Story points estimation, on the other hand, allows for a more collaborative and comprehensive assessment, considering the collective expertise and experience of the entire team, thus mitigating the effects of individual factors on efficiency and resulting in more accurate estimations.

Story Point Template

Obtain a complimentary story point template by clicking here.

FAQ

What is a Story Point in Agile?

Story points serve as units of measurement utilised to gauge the effort needed for completing a product backlog item or any other task. The team assigns story points by considering factors such as complexity, volume, and uncertainty associated with the work.

You can learn more about the agile methodology here.

How Much is One Story Point in Agile?

Story Points are a measure of the effort needed to complete a Product Backlog Item (PBI) and bring it to fruition. Each Story Point corresponds to a normal distribution of time. For instance, 1 Story Point might encompass a range of 4-12 hours, 2 Story Points could represent 10-20 hours, and so forth.

Why Do We Show Fingers to Point an Agile Story?

Many Agile teams utilise story point estimation to make predictions about release dates and shape their product roadmaps. Traditionally, these teams employ physical planning poker cards for this purpose. However, some teams have opted to abandon the card set and use hand signals instead, where each finger corresponds to a story point number on a Fibonacci-like scale. For example, showing five fingers indicates an 8-point story.

While this approach may have its proponents, I personally do not favour it and support my stance with three arguments. Firstly, even if you mentally relate 5 fingers to an 8, there is still a subconscious association between 5 fingers and the number 5. The strength of the Fibonacci scale lies in its ability to intuitively distinguish between different sizes.

Secondly, poker sets often include not only numbers but also additional symbols, such as a question mark to indicate unpreparedness for a story and a coffee card to request a break. These symbols help reduce biases and improve the overall estimation process.

Thirdly, even a fraction of a second’s delay in revealing the numbers can influence others or be influenced by them. This introduces a bias known as the bandwagon effect, where individuals tend to adopt beliefs or decisions simply because others do. The 5-finger technique potentially removes an essential element of poker: the ability to estimate independently and anonymously, as planning poker has its origins in the wideband Delphi method.

Ultimately, using physical planning poker cards with their symbols and maintaining the anonymous element of estimation provides a more robust and unbiased approach to story point estimation, leading to more accurate and reliable outcomes.

What is Agile Poker / Scrum Poker / Planning Poker?

Scrum poker, also referred to as planning poker or pointing poker, is a gamified technique employed by development teams to estimate the effort required for project management tasks. Unlike other methods, these estimations involve the entire team’s input and consensus, making them more engaging and precise. To facilitate this process and determine the number of story points for each task, teams utilise planning poker cards, resembling traditional poker cards.

What Are Story Points For Developers?

Story points serve as a method to gauge the effort needed for completing a user story in your product backlog. Typically, these story point estimations are conducted before a sprint planning meeting, as it allows your team to ascertain the workload they can undertake in the upcoming sprint.

Do you need to be a developer to create a SaaS startup? Get your answer here.

How Many Story Points Per Developer Per Sprint?

Additionally, it subtly shifts the focus away from swarming and directs attention toward assigning a developer to each story. A suitable range of 5 to 15 user stories per sprint is generally recommended. On occasion, having four stories in a sprint might be acceptable, especially in situations where workload variations occur.

How Should a Scrum Master Handle Disagreements About Story-Point Estimates in Scrum?

When the team faces challenges in reaching a consensus on a user story or task, it may indicate issues with its definition, size, or overall understanding among team members. In such cases, three essential questions come to the forefront:

Does the story/task require refinement?
Should it be broken down into separate tasks?
Does the team need to conduct research to gain a better understanding?

These situations present valuable opportunities for improvement. If the user story/task requires further refinement, it offers a learning experience for the Product Owner (PO). If breaking it down into smaller tasks is necessary, both the PO and the team gain insights into dealing with initially complex stories/tasks.

Moreover, if the team concludes that more research is needed, it signals a potential gap in understanding the technology related to that story/task. To address this, I usually allocate a one-day task for research, with specific acceptance criteria aiming to clarify uncertainties and documenting findings in a wiki or similar platform. This approach not only adjusts the team’s velocity but also enhances their capabilities and, most importantly, brings any knowledge gaps to light.

By addressing these challenges and taking appropriate remedial actions, the team can improve its performance, become more transparent about knowledge and experience gaps, and foster continuous growth and development.

Overview

In the realm of software development, Agile estimation emerges as a potent and essential tool. Embracing iterative and collaborative techniques empowers teams to achieve accurate project timelines, allocate resources wisely, and maintain transparency and adaptability throughout the development process. By employing story points, relative sizing, and other Agile estimation methods, teams can effectively break down intricate tasks into manageable components, boosting productivity and fostering a shared comprehension of the project’s scope. Additionally, the continuous reassessment of estimates in each sprint enables teams to promptly adapt to evolving requirements, ensuring that the final product meets clients’ ever-changing needs.

If you’ve enjoyed this post, we’d recommend diving into the following other posts in this Agile series:

Share Tweet Pin LinkedIn