Everything about Story Points in Agile Teams: Striking a Balance

“Should I mark this task as 5 or 8 story points?” - Is this a common question you dabble with while planning a sprint? In some form or the other, it occurs to every engineering manager whether the developer’s effort is being quantified with the right number of story points or not.

As someone who's been a CTO for more than ten years and has managed teams spread across different continents, I've personally seen the ups and downs of using Agile methodologies. One key aspect of Agile is story points, which are crucial for effective project management. But let me tell you, engineers sometimes have mixed feelings about them and can be resistant.

In this blog, I will be sharing my notes on the significance of story points, the common pitfalls that arise, the reasons engineers might dislike them, and why leaders need to embrace this practice. I will also present the ‘Framework to efficiently estimate Story points’ and provide insights into estimating tickets using story points.

‍

The Significance of Story Points

At least 100,000 years ago, if you went to the market to buy something, merchants would measure the price with shells and stones. This was an estimate that reflected the relative and subjective value of the good that you were purchasing. Today, sprint managers, and scrum masters are using a similar methodology of ‘Story Points’ to measure the developer’s effort for a given feature or task.

While the concept of story points is well stated, some aspects are ignored while planning and assigning them to a task. For instance, the seniority of the developer, the familiarity with the code, the complexity of the task, and the risk and uncertainty involved. There are ways of taking them into account while assigning story points.

As pointed out earlier, story points are a relative measure of effort that is used to estimate the complexity and size of user stories or tasks in Agile projects. They allow teams to forecast and plan their work by assigning a numerical value to each task. Story points enable a better estimation process, aiding in capacity planning, team productivity analysis, and project forecasting.

Story points create a more flexible and realistic estimation method by abstracting away from specific hours or days. This approach acknowledges the inherent uncertainties and variations in software development, allowing teams to account for unforeseen challenges and adjust their plans accordingly.

Here are a few problems that ‘Story points’ are meant to solve:

• Allow teams to break down complex features into smaller, more manageable tasks. This granularity provides visibility into progress and identifies potential bottlenecks or roadblocks early.
• Enable teams to track their velocity, providing a reliable metric for future estimations.
• Ultimately, by embracing story points, teams and leaders can foster a culture of continuous improvement and adaptability, enhancing their ability to deliver high-quality software predictably and sustainably. They can also leverage this data to optimize resource allocation,  identify skill gaps, and make data-driven decisions regarding project scope and prioritization.

In a study conducted by Atlassian, teams using story points achieved a 25% reduction in the time taken to deliver features, demonstrating the effectiveness of story points in optimizing project timelines.

If you have not been able to achieve any of them, reading further will help you.

‍

Common Pitfalls and Engineer Resistance

One of the main reasons engineers dislike story points is their association with individual performance evaluation. When story points are linked to performance metrics or comparisons among team members, it creates an unhealthy competitive atmosphere and erodes collaboration. Engineers also fear misinterpretation, potential oversimplification of complex tasks, and a lack of autonomy in estimation.

What not to do with Story Points?

There’s no way to get ‘accurate’ with story points as it’s an estimation at best.

• Try to get as close as you can to optimally plan your resources and communicate deadlines.
• Do not correlate story points with hours very soon. You will find out eventually over multiple sprints.
• Do not expect the same Story points for every developer. 5 story points for a junior developer could be 3 for a senior developer.

‍

The Importance of Story Points for Leaders

Story points empower leaders to set realistic expectations with stakeholders and ensure smoother execution of projects.

Striking a Balance

Fulfilling a culture of transparency and collaboration is vital to balance the usefulness of story points and address engineer concerns. Here are a few best practices:

1. Establish a shared understanding: Encourage open discussions among team members during estimation sessions to align on what each story point represents. This shared understanding will reduce ambiguity and improve estimation accuracy.
2. Focus on team velocity: Instead of associating story points with individual performance, emphasize the importance of team velocity. Track the team's progress collectively over time to identify trends, bottlenecks, and areas for improvement.
3. Continuously refine and learn: Regularly review and refine the estimation process based on the team's experience. Encourage retrospective discussions to identify areas where story points may not have aligned with actual effort and adjust future estimations accordingly.

‍

Framework to effectively estimate Story points

To start using this framework, I would like to present the factors that contribute while estimating the no.of story points to a feature.

Estimating Tickets Using Story Points

When estimating a ticket using story points, consider the following factors:

1. Complexity: Assess the complexity of the task, considering the number of dependencies, technical challenges, and the level of effort required to complete it.
2. Risk: Evaluate the potential risks associated with the task, such as uncertainties in technology, third-party integrations, or regulatory compliance.
3. Effort: Consider the effort required to complete the task, including research, development, testing, and any necessary iterations.

‍

The Story Points approach relies on comparing features from a current project to those of a previous similar project. This comparison enables the team to gauge the difficulty of a specific feature and assign a numerical value that reflects its complexity.

If the estimation is being done for the first time and there are no User Stories for comparison, the team must identify a Base Story and establish an Estimation Matrix. This Matrix serves as a reference point for estimating the complexity of future features.

We have listed a few use-case examples to help you estimate the right no.of story points.

Story point Estimation Matrix by Hivel.ai

The estimation matrix will be determined based on effort, complexity, and uncertainty

ScenarioEffortComplexityUncertaintyStory PointsReproducible BugLowModerateLow2Non-Reproducible BugModerateComplexHigh5Tech Debt ChangeLowSimpleLow2New Feature, New TechHighComplexHigh8Incremental Feature, Existing TechModerateModerateModerate3

Here are a few use cases listed for you to try and practice with your team. You can use this as a foundation to make estimates over a sprint planning session and ensure that you are able to plan realistically.

‍

Examples using the Fibonacci series

Here’s a small example to help explain how story points are typically assigned in agile engineering teams using the Fibonacci sequence. In this example, let's consider a task related to implementing a login feature for a web application.

Note: The assigned effort, complexity, and uncertainty values are subjective and may vary based on team interpretation. The estimated story points are allocated based on the Agile Fibonacci sequence, where each number represents a relative effort level.

Using the Fibonacci sequence (1, 2, 3, 5, 8, 13), agile engineering teams can assign story points to tasks based on their relative complexity, effort, and scope. It provides a simple scale that allows the team to estimate and plan their work effectively.

‍

Recap of Story points

Story points are a valuable tool in Agile project management, enabling leaders to make informed decisions and teams to plan their work effectively. However, to fully realize their benefits, it is essential to address the concerns of engineers and strike a balance between accountability and collaboration.

By fostering a culture of transparency, focusing on team velocity, and continuously learning from experiences, organizations can harness the true potential of story points and enhance the success of their Agile initiatives.

Story points are like a rough map for navigating through a forest - they provide a general sense of direction and help engineering teams estimate and plan work efficiently, even though they may not be perfect or provide precise measurements like detailed maps do.

‍