Navigating the Challenges of Agile Estimation: A Fresh Perspective
Written on
Understanding the Pitfalls of Estimation
In the realm of Agile, the focus often shifts to numbers, leading teams to overlook the core issues at hand.
It's 08:45, and Ivar, the Product Owner for Team Jorvik, logs onto his computer, swiftly reviewing the Product Backlog. As he prepares for the backlog refinement, he rearranges several items. By 08:57, he initiates the call, feeling a bit anxious following a particularly unproductive previous session. At 09:03, Björn joins the call. They exchange casual conversation for a few minutes until the rest of the team arrives. Growing frustrated with the delay, Ivar becomes increasingly tense as time passes. Finally, at 09:14, the entire team is present, and the meeting commences.
Ivar states, "Today, we have several items to refine. Don’t worry about a few of them; we may not tackle them for four to six months, but I need your estimates."
Harold, visibly irritated, interjects, "We have a lot on our plates right now, and you want to distract us with tasks we won't be addressing soon. Let’s concentrate!"
Ragnar adds, "I agree!"
Björn chimes in, "Absolutely!"
Ivar responds, "I understand you're busy, but we need to address these matters sooner or later. Let's redirect our focus. Our service desk team is overwhelmed, and I propose implementing a chatbot to alleviate some of their struggles. How complex will this be?"
The conversation shifts to a deep, technical discussion among Björn, Ragnar, and Harold. After ten minutes, feeling lost, Ivar interjects, "Guys! Let’s stop the technical chatter! I just need a rough estimate—nothing more!"
Björn counters, "How can I estimate without knowing what the implementation will look like?"
Harold supports Björn and shares his screen, saying, "I've done something similar before; check out this material. It’s invaluable and already available on GitHub! I can share it."
Ivar is infuriated. This meeting mirrors their last, where the team refused to provide estimates until they fully understood the implementation. Exasperated, Ivar exclaims, "I want to know how complex this chatbot is! Is it simpler or more complex than the search feature we implemented last month? I need the Story Points for it."
"EASIER!" Ragnar, Björn, and Harold respond almost in unison.
Ragnar adds, "That search was incredibly challenging. This chatbot can't be harder than that, though it might be more complex than our recommendation engine."
Ivar concludes, "That settles it! It must be a 13! The search was a 21, and the recommendation was an 8! That’s the only logical choice!"
Does this scenario resonate with you?
Let’s explore why estimation often becomes a headache for Agile teams and discuss strategies to navigate these challenges.
The Estimation Quandary
Many professionals often ask questions like:
- How can I enhance my estimation process?
- What Agile estimation techniques should I adopt?
- Should estimates be based on working days or complexity?
In my view, these questions can lead to fruitless discussions. When we concentrate on estimates, we lose sight of the underlying issues. You can refine your Agile estimation techniques or opt for a more accurate one, but if your mindset isn't aligned with Agile principles, you're likely to face the same obstacles. Here are some frequent pitfalls associated with misinterpreted estimates:
- Developers hesitate to provide estimates due to the fear of delivering inaccurate ones.
- Stakeholders tend to hold teams accountable when estimates aren’t met.
- There’s a risk of failing to deliver all promised Story Points by the end of Sprints.
"To be uncertain is to be uncomfortable, but to be certain is to be ridiculous." — Chinese Proverb
The situation outlined earlier reflects many refinement meetings I’ve witnessed. They often lack structure, resulting in frustration and missed objectives. The true aim of refinement is to clarify the problem, not the solution.
By the end of refinement sessions, Agile teams should grasp the problem they need to tackle and understand its significance. Regrettably, most discussions revolve around estimating solutions and fine-tuning requirements.
A significant trap in estimation lies in how people perceive the term. Although I am not a native English speaker, I firmly believe that "estimate" and "commitment" are not synonymous. Interestingly, Product Owners and Stakeholders often hold developers accountable for their estimates, which creates a substantial issue; it forces developers to be overly cautious with their predictions.
Escaping the Estimation Cycle
Accurately predicting the effort required by developers to implement solutions is nearly impossible due to the complexities of software development. The key to succeeding with estimates lies in accepting their inherent imprecision.
Instead of striving for precision, redirect your energy towards fostering clarity. Regardless of the estimation technique employed, the primary goal is to cultivate a shared understanding within the team. Do all developers view the situation similarly? If they don’t, then you’re not ready to proceed. My preferred estimation technique is planning poker. It’s straightforward, dynamic, and informative.
For example, when one developer estimates a task as a 3 and another as an 8, it’s clear they perceive the task differently. By discussing their reasoning, the team benefits from diverse viewpoints, which aids in progress. Ultimately, they may come to a consensus on a 3, 5, or 8, but what truly matters to me as a Product Leader is whether the team shares an understanding of the problem—not the specific number assigned.
"There is nothing so useless as doing efficiently that which should not be done at all." — PETER DRUCKER
I recently encountered an analogy that resonated with me: we should shift from estimating to forecasting. Consider a weather forecaster. If you check the forecast for a week ahead, you can be sure it will evolve as new information emerges. This is because the forecaster adjusts their predictions based on the latest data. Therefore, I encourage teams to re-estimate regularly.
Final Insights
After over a decade of collaboration with Agile teams, I’ve learned to remain indifferent to estimates. My primary concern is the understanding that the team develops, rather than the numbers assigned to each item in the Product Backlog.
Here’s my recommended approach for sustainable Agile estimation:
- Set the stage: The Product Owner explains the problem behind the User Story and its importance.
- Questions: Developers pose questions to clarify the problem and its specific requirements.
- Clarity: The Product Owner addresses any uncertainties with the team.
- Estimate: Developers assess the complexity of addressing the problem.
This process should ideally take no longer than ten minutes. If it extends beyond that, it signals that the team is already delving into the implementation or focusing on effort rather than complexity.
A vital aspect of agility is embracing uncertainty. Estimates can be detrimental as they often hinder Agile practices. By concentrating on actions to alleviate our insecurities, we risk reverting to traditional patterns.
Truly Agile teams accelerate their learning curve to deliver value sooner, without becoming overly attached to any particular process.
Agile Estimations Techniques Suck - A critical look at common estimation pitfalls in Agile environments.
Why Software Estimations Are Always Wrong - Understanding the challenges of software estimation and how to navigate them.