Challenges in Agile Estimation
#TechnologyAtTyme | Agile estimation is a practice utilized by teams following Agile methodologies to determine the amount of work, uncertainty, and complexity required for backlog items. It is a collaborative process that involves the entire team and ensures a shared understanding of the work ahead.
You may encounter some common challenges as an Agilist striving to apply agile practices within your organization. These hurdles can impact the estimation process and the overall success of your Agile initiatives. Let’s explore some of these challenges and discuss how to overcome them effectively.
When Shared Understanding Falls Behind Numbers
It’s essential to address some misconceptions about estimation, as people often treat it merely as a numerical exercise, leading to unnecessary arguments and disagreements. However, estimation is more than assigning numbers or applying various techniques; it cultivates mutual comprehension of project or product expectations, user issues, and the suggested solutions.
For instance, when a product backlog item needs to be estimated, team member A might offer an estimation of 3 points, and then team member B could suggest 5 points, with both providing their reasoning behind these numbers. However, instead of striving to comprehend and respect each other’s viewpoints, they emphasize their opinions. Alternatively, some might opt to calculate an average estimation. For instance, if one member rates it as 3 points while another rate it as 8 points, they would settle on an estimation of 5 points for the item.
When teams face challenges with estimation, the root cause is usually a lack of shared understanding rather than a flaw in the estimation process itself. By addressing the shared understanding problem, teams can overcome estimation difficulties more effectively.
Shared understanding problems can arise due to various organizational dysfunctions. On the product side, insufficient business involvement, a lack of understanding of the business problem, and incomplete requirements decomposition can hinder the sprint planning process. This often results in lengthy planning meetings that lack the necessary level of detail.
To overcome shared understanding problems and improve estimation accuracy, it is crucial to address the organizational dysfunctions causing these issues. Encouraging more business involvement, ensuring a comprehensive understanding of the business problem, and facilitating thorough requirements decomposition are vital steps. Additionally, teams should focus on conducting detailed discovery discussions during sprint planning to gain a clearer picture of the tasks at hand.
Individual Differences Matter
Assigning the same user story to ten developers with the required technical expertise does not guarantee identical completion times. In Agile teams, individual differences in skills and working pace are natural.
Each team member brings unique skills and approaches, influencing their productivity. While technical expertise is vital, creativity and problem-solving abilities also play a significant role.
Knowledge work involves multiple iterations of trial and error, impacting completion time. Adaptability and collaboration are key to optimizing productivity.
In Agile, embracing variability enables teams to leverage individual strengths and achieve successful outcomes effectively.
Estimating Input or Output?
When it comes to Agile estimation, many new teams adhere to their old practice of time-based estimates, equating 1 day of effort to 1 story point. However, this approach may overlook an essential consideration — variability in the time required to complete tasks based on individual developers’ experience.
Consider a user story that could be handled by either developer X or developer Y. X, an experienced developer, estimates completing the story in 3 days, sizing it as 3 story points. Meanwhile, a relatively less experienced developer, Y foresees 5–6 days to complete the same story, sizing it as 5 points.
This difference in estimation stems from thinking in input terms — how much effort each developer puts into the task. However, let’s shift our perspective to think in output terms — how much work is actually accomplished when X or Y works on it.
Surprisingly, the output, in terms of functionality completed, remains the same for both developers. While the input (effort spent) may vary, the output remains constant. Therefore, the team’s accomplishments and the client’s payment should be based on output rather than input.
During my time here, I’ve encountered a consistent pattern: Whenever I request the team to provide estimates, the senior developers have the tendency to base their estimations on their own past experiences and the time they believe a task will take rather than considering the actual workload, complexity, or associated risks. To address this, we’ve found a solution. We encourage team members to enumerate the tasks involved. During this process, those “aha” moments occur as individuals begin to grasp the work undertaken by their colleagues and the reasons behind the necessary level of effort to fulfill the user story successfully.
In conclusion, Agile teams should prioritize output-based estimation, focusing on the functionality delivered rather than individual input, to ensure fair and accurate estimations that align with the project’s success.
Agile practitioners often find themselves falling into these challenges, and it can be difficult to break free from them. Through this article, I aim to raise awareness among agile practitioners, enabling them to identify these common challenges easily and find suitable solutions tailored to their context. Navigating conversations effectively during estimation practices is essential to overcoming these obstacles and ensuring smoother project execution.
Written by @Tai Nguyen — Scrum Master, TymeX
— — —
For more TymeLabs — Articles:
