The Challenge of Estimating in Agile: Embracing Uncertainty, Planning for Predictability, and Building Great Products

The Problem: Estimating in Agile is a Struggle We All Face

Picture this: you’re in a planning meeting, surrounded by your team. There’s a new feature that everyone is excited about, but the excitement quickly turns into uncertainty as the inevitable question arises—"How long will this take?" The developers look at each other, each with a different number in mind, while the product owner anxiously checks the roadmap. Meanwhile, stakeholders are pressing for a delivery date, hoping for a clear answer. Sound familiar?

Estimation in Agile is one of the most challenging aspects for teams. It’s not just about assigning numbers; it’s about grappling with the unknowns, dependencies, and complexities that come with every task. There’s constant pressure to translate abstract story points into days or hours, and when those estimates miss the mark, the fallout can feel overwhelming. Developers feel pressured, product owners are caught between conflicting priorities, and stakeholders often perceive Agile as a chaotic process without clear plans.

The Misconception: Agile is Unpredictable and Without Plans

One of the biggest myths about Agile is that it’s all about embracing chaos and rejecting predictability. Many stakeholders worry that working Agile means there are no plans, just constant pivots. But the truth is, Agile involves a significant amount of planning—just not in the traditional sense. Instead of one grand plan, Agile emphasizes ongoing, iterative planning at multiple levels: Epics, Features, user stories, and tasks. This approach allows teams to remain flexible, adapting scope within short, fixed time periods while still maximizing the value delivered.

Agile Has Predictability—Just Not the Way You Expect

While Agile isn’t designed to plan months of work down to the hour or promise specific delivery dates for features or Epics, it does provide a framework for understanding uncertainty and managing it effectively. The predictability in Agile comes from the team's ability to identify risks and uncertainties early on through continuous estimation and planning.

As the team estimates Epics and aligns them with the Product Backlog, they uncover the potential risks and unknowns associated with each feature. This insight allows them to decide whether an Epic or feature is worth pursuing with the current level of risk, or if they need to go back to stakeholders and UX/UI teams to consider alternative approaches.

Estimation helps the team understand what they are getting into before fully committing. If points indicate that a feature is much larger or riskier than anticipated, they can adapt before moving forward. If the burndown or burnup charts show that work isn’t progressing as planned, it signals that something is off—whether it’s an overburdened team member, an emerging risk, or a newly discovered obstacle that threatens the sprint goal. This triggers a critical conversation about whether to adjust the scope, absorb the risk, or shift priorities—all of which could impact the roadmap.

This is why Agile is synonymous with flexibility and adaptability. It’s not about forcing the team to hit sprint goals or stick to a predetermined release date; it’s about responding to change. The true cost of pushing for a forced release with potential bugs, burnt-out employees, and rushed, unvalidated features is often far greater than taking the time to adapt. Adjusting the scope of user stories, revisiting the next feature in the Product Backlog, or tweaking the version expected for user testing can save the company time, money, and resources in the long run.

A Common Pitfall: The Hidden Risks of Infrastructure and Resources

During product discussions, the development team often focuses on finding a way to make the feature work. They dive into the “how” of the “what” posed by the product manager or owner, and everyone leaves the meeting feeling optimistic. But there’s often a critical element that gets overlooked: infrastructure, tools, and resources.

Teams might talk about Terraform, Glue jobs, IAM, Jenkins, environments, and CI/CD pipelines—but these discussions rarely make it to the product side of the room. There’s a gap in understanding that these aren’t just technical details; they are crucial parts of the product that need to be planned, funded, and supported.

For example, a Minimum Viable Product (MVP) might work with a free API that has limitations, a free-tier AWS account, or mock data on small tables. But what happens when the project scales? What if the API costs become prohibitive, or the free-tier infrastructure becomes a bottleneck? Suddenly, something that seemed like a straightforward 3-point task balloons into 100 points because the underlying resources aren’t feasible.

This is where the role of the Tech Lead becomes essential in estimation. The Tech Lead helps translate the technical requirements and risks into terms that product managers and stakeholders can understand, ensuring that these factors are considered in the planning process. Without this input, teams can find themselves blindsided by delays, unplanned costs, or technical debt that wasn’t factored into the initial estimates.

Scaling Agile Estimation: Different Roles for Different Levels

In small teams or startups, it’s often feasible to have everyone in the same room for planning, refinement, or grooming sessions. But as organizations grow, with multiple teams working in parallel and layers of management such as VPs, SVPs, and C-level executives, it becomes impractical and costly to include everyone at every level of estimation.

Scrum guidelines might suggest having a four-hour planning session for a two-week sprint or a full day for a month-long sprint, but realistically, each level of planning needs to be broken down to manageable pieces with the right people in the room. When reviewing a feature, different decisions and adaptations are made compared to those at the user story level. And that’s okay—different roles participate in different sessions depending on the scope and focus of the discussion.

Stakeholders don’t necessarily need to attend the sprint planning where development tasks are broken down, just as developers might not be essential in high-level feature discussions about an Epic’s scope. What matters is that the appropriate roles are present in each planning session to ensure that decisions are well-informed and align with the team’s goals and capabilities.

The Power of Agile Estimation: A Process of Discovery

At the heart of Agile estimation is the principle of collaboration. Estimation isn’t just about predicting how long something will take—it’s about having conversations that surface the uncertainties, dependencies, challenges, and team biases that could impact delivery. The goal is to bring together the collective experience of the team to make better decisions.

Consider this story: A child who loves to draw is asked if he could recreate the Mona Lisa. Without hesitation, the child confidently says, “Yes, I can do it in a day.” Then, an experienced artist is asked the same question and explains that he could create a similar work but would need several months to do it justice. Faced with these two options, the decision-makers choose to pay the child.

The next day, the child delivers a crayon drawing that, while charming, looks nothing like the Mona Lisa. This is the child’s capacity, his interpretation of what was asked. If the artist and child had sat together and discussed technique, materials, expectations, and the desired outcome, the child might have realized the true scope of the task and said, “This will take me years to learn.”

This is why Agile teams estimate together. We’re not just assigning numbers; we’re discussing what it will take to meet the shared vision. Estimation helps us align on what “done” looks like, and it allows the team to understand the complexities and effort required before committing to work.

How Agile Estimation Works: Tools for Better Planning

Agile estimation uses a variety of tools to facilitate these conversations and make the process transparent:

1. Scrum Poker (Planning Poker): This is a consensus-based estimation technique where team members each play numbered cards face down to estimate the effort of a task. The cards are revealed simultaneously, and any significant differences in estimates are discussed. The goal is not to argue about numbers but to uncover the uncertainties and differences in understanding that drive those estimates. For example, why did someone think this story was a “5” when others saw it as a “2”? These discussions help clarify the scope, identify potential risks, and ensure everyone is aligned.

2. T-Shirt Sizing (S, M, L, XL): T-shirt sizing is a way to quickly categorize the relative size of tasks without getting bogged down in numbers. It’s useful for higher-level planning, such as estimating Epics or Features before they are broken down into user stories. By agreeing on what constitutes a “Small” vs. a “Large” task, teams can make faster decisions about prioritization and scope.

3. Fibonacci Sequence (1, 2, 3, 5, 8, 13, etc.): The Fibonacci sequence is often used in Scrum Poker to assign points because it reflects the increasing uncertainty as task sizes grow. A task estimated as a “1” is straightforward, while a “13” suggests high complexity and potential unknowns. This scaling helps teams avoid overly precise estimates for complex work and emphasizes the need to break down large tasks into more manageable pieces.

The True Value of Estimation: Conversations Over Numbers

Estimation isn’t about precision; it’s about creating a shared understanding. Every discussion during estimation is an opportunity to explore uncertainties, express doubts, and share experiences. It’s common for biases to emerge—some team members might be overly optimistic, while others might be more cautious based on past challenges. The value of these conversations is that they help align the team, surface potential issues early, and set realistic expectations for what can be achieved.

Through estimation, we build a collective picture of what it will take to deliver the work. We learn together, refine our plans, and adapt our approach as new information comes to light. It’s a dynamic process that ensures we’re always working on the right things and delivering the highest value possible.

Step-by-Step Guide to Agile Estimation

Here’s a practical guide to implementing Agile estimation in your team:

1. Identify the Big Picture with Epics and Features: Start with high-level planning. Break down your product vision into Epics (large units of work) and Features (smaller, more defined components of those Epics). Use T-shirt sizing to give rough estimates for these larger items.

2. Refine Epics into User Stories: As Epics and Features are prioritized, refine them into user stories—specific, actionable pieces of work that deliver value. This is where Scrum Poker comes in. Use Planning Poker to estimate stories, encouraging the team to discuss their thoughts, concerns, and questions.

3. Break Stories into Tasks: Once stories are estimated, break them down into tasks that can be completed in a day or less. This step is crucial because smaller tasks are easier to estimate accurately, track, and adjust. It’s also where the team starts to visualize the work and make daily progress.

4. Estimate Frequently, Not Just During Sprint Planning: Estimation should be an ongoing process, not confined to sprint planning. Use regular backlog grooming sessions to update estimates as new information comes in. This approach keeps your estimates current and relevant.

5. Use Velocity as a Planning Tool, Not a Goal: Track your team’s velocity—the average number of points completed each sprint. Use this data to inform future planning, but don’t treat it as a target to hit. Velocity helps you understand your team’s capacity and make realistic commitments.

6. Monitor Progress with Burndown/Burnup Charts: Visualize your progress with burndown or burnup charts, which show how much work remains versus how much time is left. These charts provide a reality check and help teams identify if they’re on track or if adjustments are needed.

Conclusion: Agile Estimation Drives Efficiency, Learning, and Success

Agile estimation is not just a collaborative exercise—it’s a powerful tool that enables organizations to deliver value faster, validate hypotheses sooner, and learn cheaply from failures or successes. While Agile’s adaptive and flexible approach may seem less predictable than traditional project management, it’s actually a far more effective way to manage investment, time, and resources.

By breaking work into smaller, manageable chunks and continuously planning at different levels, Agile estimation acts like compound interest: each sprint, each cycle adds value that builds on the last. This approach exponentially increases the chances of success, unlike the linear “under-the-mattress” approach of traditional planning, which feels safe but loses value over time.

The iterative nature of Agile estimation reduces delegation to static documentation and project handoffs, requiring all team members to be actively involved in the process. This involvement ensures that everyone is aware of the current state, risks, and adjustments, which increases the probability of success. In a world where only 40% of large-scale projects succeed, breaking work into hundreds of smaller “mini-projects” through Agile estimation raises the overall success rate significantly.

Ultimately, Agile estimation is about creating a structured yet adaptable process that maximizes learning and minimizes waste. It transforms uncertainty into manageable steps, allows teams to adapt quickly, and aligns everyone toward the shared goal of delivering high-quality products to market faster. It’s not just about being flexible; it’s about being effective, efficient, and always moving forward.