“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.
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:
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.
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.
There’s no way to get ‘accurate’ with story points as it’s an estimation at best.
Story points empower leaders to set realistic expectations with stakeholders and ensure smoother execution of projects.
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:
To start using this framework, I would like to present the factors that contribute while estimating the no.of story points to a feature.
When estimating a ticket using story points, consider the following factors:
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.
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.
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.
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.