Please don’t do it! 1 Story Point is not 1 Engineering Hour!

In Agile software development, Scrum has become one of the most popular frameworks for managing projects. One key concept in Scrum is using story points to estimate the effort required to complete a user story. However, it is essential to understand that story points differ from engineering hours. While this article uses the Scrum example, this concept applies to other Agile estimation techniques. This article will explore why equating 1 story point to 1 engineering hour is incorrect and how this principle applies to other Agile estimation methods.

An Introduction to Story Points

In computer programming, when a team is working on a project, they need to know how much time and effort it will take to complete different tasks. Instead of trying to guess how long each task will take, they use a system called “story points.”

Story points help the team figure out how difficult each task is, based on how complicated it is, how much they don’t know about it, how many other tasks it depends on, and how much skill they need to finish it. They use particular numbers, like 1, 2, 3, 5, 8, and 13, to rate each task’s difficulty. This way, they can better plan how much work they can do in a certain amount of time.

Story points differ from counting how many hours each task takes because everyone works at different speeds, and some tasks are more complex than others. With story points, the team can ensure everybody is doing their best without worrying about how many hours it takes them.

Factors Affecting Effort

Regardless of the Agile estimation technique, several factors influence the effort required to complete a user story. These factors include:

Complexity

Complexity measures how difficult or intricate a task is to complete. It can be affected by various factors within a user story, such as the number of features or functionalities involved, the level of technical proficiency required, or the need for integration with other systems or components. Appropriate research, analysis, or coordination with other team members may be required to evaluate the complexity of a user story. This may involve reviewing documentation, consulting with subject matter experts, or conducting user testing.

The complexity level can significantly impact the number of story points assigned to a user story. More complex stories will generally require more points to complete, reflecting the increased effort and resources required to deliver the functionality successfully. It is essential to carefully evaluate the complexity of a user story to ensure that it is accurately scoped and planned for. Failing to account for complexity properly can lead to delays or unexpected roadblocks later in development.

Uncertainty in User Stories

Uncertainty in user stories refers to unknowns or risks associated with a specific task or feature. When a task involves high uncertainty, more story points may be assigned to account for the additional effort required to address potential challenges or obstacles.

Several factors can contribute to uncertainty in user stories. One common factor is unclear requirements; when requirements are not well-defined, estimating the effort required to complete the task can be challenging. Another contributing factor is limited domain knowledge; when team members are unfamiliar with the domain or technology involved in the task, it can be challenging to anticipate potential obstacles. Dependencies on external systems or teams can also increase uncertainty, as unforeseen issues with these dependencies can impact the completion of the user story.

It’s important to note that uncertainty is not always a negative factor in user stories. In some cases, uncertainty can lead to innovation and creative problem-solving. However, managing uncertainty proactively is essential to avoid delays or unexpected roadblocks. The higher the level of uncertainty, the more critical it is to involve relevant stakeholders and subject matter experts in the planning and execution of the user story.

Dependencies

Dependencies are an essential aspect to consider when working on a user story. These tasks or activities must be completed before a user story can be worked on. It is important to note that the number of dependencies can affect the effort required to complete the user story. For instance, if a user story has many dependencies or requires coordination with other teams or departments, more story points may be assigned to reflect the additional effort needed for coordination and collaboration.

Moreover, it is crucial to understand that dependencies can impact the effort required to complete a user story in several ways. For example, if a user story relies on the completion of tasks by other teams, any delays or issues in their work can affect the overall effort required. Similarly, additional effort may be needed to ensure smooth integration and collaboration if a user story requires coordination with external stakeholders or third-party systems. Considering all these factors when working on a user story is essential to ensure its completion.

Skill Level

When it comes to user stories, the team members’ skill level can have a significant impact on the time and effort required. It may take longer to complete if a task requires specialized knowledge or expertise limited to only a few team members. This is especially true if additional training or research is required to tackle the task.

It’s essential to remember that team members’ skill levels can vary greatly. Some team members may be more experienced than others, affecting a task’s time. For example, a task that requires advanced programming skills or deep domain knowledge may be easier for an experienced team member to tackle than a less experienced one.

That’s why it’s essential to consider the overall skill level of team members when assigning story points. By doing so, you can ensure that tasks are assigned to team members with the right expertise and knowledge to complete them efficiently and effectively. This helps reduce the overall time and effort required to complete a project while ensuring that the final product is of the highest quality.

Why 1 Story Point is not 1 Man-Hour

While story points measure effort, they are not equivalent to engineering hours. Here are a few reasons why:

Individual Differences

It is essential to acknowledge that team members may have varying levels of productivity and efficiency. Some team members may be more experienced or have a different work style affecting their ability to complete tasks. Personal circumstances such as family obligations or health issues can also impact an individual’s ability to complete work at the same pace as their teammates.

Teams can use story points to address these differences instead of focusing solely on time-based estimates. Story points consider the relative effort required for a task rather than just the amount of time it will take. This allows for a more accurate estimation of effort that considers each team member’s unique strengths and challenges.

Furthermore, individual differences can also arise from differences in expertise or knowledge. For example, one team member may be more familiar with a particular programming language or tool, while another may have more experience in project management. Using story points, teams can account for these differences in expertise and ensure that each team member is assigned challenging and achievable tasks.

Equalizing Team Delivery

If 1 story point were equivalent to 1 engineering hour, it would imply that all team members have the same level of productivity and efficiency. This would make it difficult to differentiate between team members in terms of their contribution and impact on the project. Using story points, the focus shifts from individual working hours to the collective effort required to complete a user story. This allows for a more accurate representation of the team’s capacity and helps plan and prioritize work accordingly.

Story points provide a fair and balanced approach to estimating effort, considering the team’s collective effort rather than individual contributions. This approach helps foster a collaborative and supportive team environment that focuses on collectively achieving the project goals.

Example from Experience

To illustrate the difference between story points and engineering hours, let’s consider an example from personal experience. In one of the companies I worked for, the team used a conversion rate of 3 story points equal to 1 day. However, there was a significant difference in productivity between a senior engineer and a more junior engineer.

The senior engineer created over 1000 lines of code daily when working on a “CRUD” feature, while the junior engineer could only deliver around far fewer than that. If we were to equate story points to engineering hours and assign them to all, it would imply that the senior engineer’s productivity was the same as the junior engineer’s, which is simply wrong.

However, by using story points, we can account for these individual differences in productivity. The senior engineer’s work may be assigned more story points due to the complexity and effort involved. The junior engineer’s work may be assigned fewer story points. This approach allows for a fair and accurate estimation of effort, considering the skills and capabilities of each team member. It also helps avoid unfair comparisons and promotes a focus on the collective effort required to complete a user story.

So How to Do It The Right Way?

Let’s say we all agree to do agile estimation using Fibonacci numbers. We can follow these steps:

1. Define the Fibonacci sequence: The Fibonacci sequence is a series of numbers where each is the sum of the two preceding ones. The sequence typically starts with 0 and 1, resulting in 0, 1, 1, 2, 3, 5, 8, 13, and so on. These numbers will be used to assign story points to user stories.
2. Create a reference story: Start by selecting a user story representing your team’s average level of effort. This story will be a reference point for assigning story points to other user stories. Assign a story point value to this reference story, such as 5 or 8.
3. Estimate other user stories: Compare each user story to the reference story and assign a story point value based on its relative complexity and effort required. Use the Fibonacci sequence to assign story points, such as 1, 2, 3, 5, 8, 13, etc. Here are some guidelines for assigning story points:

• Story point 1: Imagine the most straightforward day-to-day task, such as changing the string value in an application.
• Story point 2: Twice as complex as story point 1.
• Story point 3: Three times the complexity of story point 1.
• Story point 5: Equivalent to the combined complexity of story point 2 and 3.
• And so on, following the Fibonacci sequence.

1. Be careful with bug-fixing tasks: When assigning story points to bug-fixing tasks, it’s essential to consider the nature of the bugs. Fixing production bugs might be considered a productive task and given a story point value greater than 0, as it contributes to the stability and reliability of the software. However, fixing development bugs, which are bugs found during the development process, is not considered a productive task. Assigning story points to development bug-fixing tasks is not recommended, as it can lead to misleading productivity metrics.
2. Discuss and reach a consensus: Estimation should be a collaborative process involving the entire Agile team. Discuss the complexity of each user story, considering technical challenges, dependencies, and risks. Reach a consensus on the story point value for each user story through open and transparent communication. The conventional way to reach this consensus is by using planning poker, but magic estimation works well if you need faster iteration (it could be 4–5 times or even faster).
3. Revisit and refine estimates: As the team gains more experience and knowledge throughout the project, revisiting and refining the estimates is essential. This can be done during Agile ceremonies like sprint planning or backlog refinement sessions. Adjust the story point values based on new insights and learnings.
4. Handling unknown complexity: For better estimation, it is recommended to mark story point 13 as unknown. Story point 13 should be broken down into smaller tasks with more minor story points to understand the complexity better.

By following these steps and considering the nuances of bug-fixing tasks, your Agile team can effectively estimate user stories using story points and the Fibonacci sequence, enabling better planning and resource allocation.

Estimating Project Completion Time

While story points are not directly equivalent to engineering hours, they can still be used to estimate the time needed for project completion. By analyzing historical data and observing the team’s velocity, which is the number of story points completed in a given period, it is possible to make predictions about future project timelines.

A proper Agile implementation emphasizes the collection and analysis of data throughout the project lifecycle. This data includes the number of story points completed in each sprint, the team’s velocity, and any factors that may have influenced the team’s performance. By tracking this data over time, teams can gain insights into their capacity and productivity.

Using this historical data, teams can calculate their average velocity and estimate the sprints required to complete the remaining work. For example, if the team’s average velocity is 20 story points per sprint and 100 story points remain, it can be estimated that the project will take approximately 5 sprints to complete. Thus, assuming the sprint length is 2 weeks, we can give the stakeholders the remaining time estimate of 10 weeks.

However, it is essential to note that these estimates are based on historical data and assumptions about future performance. Agile projects are inherently adaptive, and unforeseen factors can impact the team’s velocity. Therefore, these estimates should be treated as guidelines rather than fixed deadlines. An accurate Agile implementation encourages teams to continuously monitor and update their estimates as new information becomes available. By regularly reviewing and adjusting estimates based on actual progress, teams can make more accurate predictions about project completion time.

Conclusion

In a so-called agile team, understanding the difference between story points and engineering hours is crucial for effective project management in Agile environments. Story points provide a more flexible and collaborative approach to estimating effort, considering complexity, uncertainty, dependencies, and skill level. Using story points, you can ensure that your team’s capacity and capabilities are accurately represented, allowing for better planning, prioritization, and value delivery in Agile software development projects. This principle applies to Scrum and other Agile estimation techniques, emphasizing the importance of relative effort estimation over fixed time estimates.

Using a fixed conversion rate of 1 story point equals 1 engineering hour can introduce unnecessary unpredictability to the project, especially considering team members’ skill levels and experience. Using story points, the team can account for individual differences and adjust estimations accordingly. This approach ensures a more accurate estimation of effort and helps manage expectations and project timelines.

To truly embrace Agile methodologies, it is essential to have a deep understanding of the Agile Manifesto and principles. Agile is not just about using jargon or following a set of practices; it is a mindset and a way of working that values individuals and interactions, working software, customer collaboration, and responding to change. By correctly understanding and applying Agile principles, teams can create a culture of transparency, collaboration, and continuous learning, leading to more successful projects and better outcomes, including embracing the correct Agile estimation process of assigning story points.

So next time your so-called jargon-heavy agile coaches say that 1 story point equals 1 engineering hour, you can say no and explain the whys to them.

—

PS: Hi there! My name is Yoka, and I am a software engineering manager with a deep passion for software engineering craftsmanship. If you like this article, you might like https://www.ayokoding.com, a website where I write about software engineering craftsmanship, engineering management, and my learning experience. Or, if you are in the Twitter space, feel free to follow AyoKoding at https://twitter.com/ayokoding.