Estimating the time and effort required to complete work is important for Agile teams (and teams that aren’t necessarily Agile but want to become more efficient). By estimating when work items can be completed, teams are able to plan their work accordingly and focus on more high-value delivery.
The problem? It can be very challenging to accurately predict how long work will take, especially if a work item is complex or new. That’s where Agile estimation techniques come in. These techniques help teams come together and collaboratively estimate tasks, providing a great starting point for planning complex work.
Estimation techniques in Agile can make a huge difference for teams as they respond to change, aim to deliver value early, and align on what’s possible. Like many other aspects of Agile, estimation is iterative, and teams can refine estimates throughout their workflow, constantly making adjustments as they gain more information.
Read on to learn about the top Agile estimation techniques, how to choose the technique that’s right for your team, and tips for improving your estimation.
What is Agile estimation?
Agile estimation is a method that teams can use to gauge certain factors that will impact the completion of work, such as complexity, effort, relative size, time, risk, and uncertainty. Any Agile estimating technique can focus on one or some of these factors.
The most effective teams treat estimation as a collaborative, team-based activity intended to allow everyone to weigh in. It’s acknowledged that everyone’s making the best guess with the information they have available at the time. When a team estimates together, team members uncover hidden complexities, build a shared understanding, and foster collective ownership.
In some organizations, Agile estimating is still handled primarily by tech leads and senior developers with infrequent involvement from the broader team. While this can seem quicker and more efficient, it often leads to missed insights, misaligned expectations, and a lack of shared ownership. Without broader team involvement, teams are at risk of underestimating complexity, making flawed assumptions, and ultimately spending more time correcting issues later on—all of which undermines the efficiency they were originally seeking.
Each team member has the power to update or push back on estimates at any time; estimates shouldn’t be made only during events such as sprint planning or backlog refinement, but any time new information becomes available. Regularly revisiting estimates ensures that the workload remains realistic and doesn’t exceed the team’s capacity.
“Estimation is not a static agreement but rather an evolving and ongoing conversation that’s part of the work.”
—Bryan Stallings, chief evangelist, Lucid
Why is Agile estimation important?
Agile estimation is important because when done effectively, estimation can help businesses navigate common challenges, including volatility, risk, changing priorities, and technical complexity. Estimation can also directly impact business outcomes by leading to increased predictability, better release plans, more high-value delivery, and higher stakeholder satisfaction.
On a team level, estimation fosters discussion, aids in achieving consensus, and enhances alignment and collaboration. Teams benefit from estimation as it helps them set shared expectations, plan realistic workloads, and maintain a sustainable pace to prevent burnout. When teams are able to track their expected amount of work versus the actual amount, this informs future estimates and they’re able to continuously improve.
Common units of estimation
Before we get to the estimation techniques themselves, there are some important units of estimation, or estimation scales, to understand. Many estimation techniques use these units in order to assign value to estimation, taking into account factors such as complexity, risk, and uncertainty.
When teams are summing up estimation units (such as story points) that are completed during a period of time (such as a sprint), that sum is a useful estimation metric for teams. A word of warning on metrics, however: While estimation metrics are incredibly useful, management can sometimes misuse metrics. Sometimes leaders in an organization become too attached to metrics and begin to regard them as a cardinal rule—asking teams to do whatever they can to accomplish the metric, regardless of the consequences—rather than regarding it as something that can be adjusted.
To avoid the misuse of metrics, you can help your leadership understand why you are trying to use estimates for workload, what decisions this data will inform, and the effect metrics can have on team behavior.
Overall, the intent of estimation isn’t to ensure work is always completed in exactly the same way but to improve predictability and enable continuous improvement. Estimation should help teams refine their planning and decision-making rather than force them into rigid processes.
“Estimation metrics are a tool to help make decisions; they are not strict goals to meet. It’s helpful for teams to keep in mind that metrics are only part of the story for estimation.”
—Jessica Guistolise, evangelist, Lucid
The three most common units of estimation are the Fibonacci sequence, story points, and T-shirt sizes. Before we get to that, however, there’s a method to estimation units that’s important to understand: Relative estimation.
Relative estimation
What is relative estimation in Agile? Agile estimation relies on comparing work items rather than trying to predict exactly how long something will take to complete in terms of absolute time (such as hours or days). Teams first estimate the size of a work item and then derive its duration based on past experience or they compare the complexity of one item to another.
This approach helps teams make faster, more consistent decisions. Agile relative estimation also acknowledges that different team members work at different speeds, unknown factors often emerge as work goes on, and exact time estimates can be misleading.
A key principle of relative estimation is "estimate size, derive duration." Rather than asking, “How long will this take?” teams ask, “How big is this compared to other work we’ve done?” Once size is established, teams use historical data of how much work they typically complete in a timebox, such as a sprint, to determine how much work they can take on in a given timeframe.
For example, if a development team is using relative estimation, team members have a rough sense of how “large” each work task is compared to the others. If team members know from experience that they can usually finish one large task per week, they can plan their workload without needing to estimate exact times for each item.
The two most common ways to apply relative estimation are by using story points and T-shirt sizes. First, however, we’ll begin by explaining the Fibonacci sequence.
Fibonacci sequence
The Fibonacci sequence is a series of numbers that are the sum of the two preceding numbers, such as: 0, 1, 1, 2, 3, 5, 8, 13, etc.
This sequence is commonly used in Agile as a more realistic way to approach estimation. As teams assign numbers to work items, higher values indicate greater complexity and effort. Fibonacci numbers work well because they grow at an increasing rate rather than linearly, which helps teams account for the expected difficulty when facing complex, large work items. Estimates also tend to be overly optimistic and inaccurate, so using the Fibonacci sequence helps teams estimate with more accuracy.
By using the Fibonacci sequence as a unit, teams can more easily account for delays, dependencies, and other blockers that may prevent a work item from being completed within the estimated amount of time. In fact, many Agile estimation techniques rely on the Fibonacci sequence.
