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?

Estimation is a method that teams can use to gauge certain factors that will impact the completion of work. These factors include complexity, effort, relative size, time, risk, and uncertainty. Any estimation 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, estimation 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?

When done effectively, estimation can help businesses navigate common challenges, including volatility, risk, changing priorities, technical complexity, and more. Intentional estimation can 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 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. Remember, for example, that a single story point is a unit of estimation. When you’re adding up how many story points your team completed during a sprint, this becomes an estimation metric.

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

Many Agile estimation scales rely 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, known as relative estimation, helps teams make faster, more consistent decisions. 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 content team is using relative estimation, team members have a rough sense of how “large” each work task is compared to the others. Writing the copy for an email or for a web page may feel similar in effort, so those are “medium” tasks while writing a long-form blog post is a larger task. 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 with 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.

 

Story points

Story points are a common unit of measure representing the overall effort, complexity, and uncertainty involved in completing a work item. They’re meant to be used as an abstraction of effort, moving teams away from the constraints of thinking in hours and days to instead consider the relative effort required for a task. If an item is estimated to take a larger amount of effort (again, due to complexity and uncertainty) then it’ll receive a larger amount of story points value. 

The numbers assigned to story points follow the Fibonacci sequence. In Agile, the sequence for story points typically goes as: 1, 2, 3, 5, 8, 13, etc. 

To assign story points, consider the following factors: 

• Risk, such as whether the work item may have dependencies that need to be eliminated or mitigated. 

• Complexity, determined by how difficult the item is to develop. 

• Relative effort, as in the amount of effort estimated relative to other work items. 

• Familiarity, determined by how familiar an individual is with the item. 

By assigning story points, Agile teams can more accurately plan sprints and estimate workload at any time. Story points can be used for many estimation techniques in Agile.

T-shirt sizes 

Similar to story points, T-shirt sizes are a unit of estimation that teams use to estimate an item’s relative size (in terms of complexity, effort, risk, and uncertainty). Rather than numbers, in this case, items are assigned T-shirt sizes: XS, S, M, L, XL. If an item requires a small amount of effort (for example, a quick weekly task that an individual is very familiar with), then that item may be assigned XS. 

T-shirt sizes are a popular estimation unit because they help teams estimate quickly and can be a fun team estimation activity. T-shirt sizes help teams think outside of the box and are particularly useful for identifying larger work items that need to be broken down further. 

Top 4 Agile estimation techniques 

Estimation techniques aren’t only beneficial for managing your workload—they also support team collaboration by giving everyone a chance to weigh in. Each of the following techniques can be completed in person or virtually, with a visual collaboration platform and templates to help facilitate the discussion. Estimation can also be done asynchronously, especially as individuals make updates to their original estimates.

With that in mind, here are the top four Agile estimation techniques (with information at the end on an alternative approach) that you can use anywhere, anytime with your team. 

Planning poker

Planning poker is a fun estimation technique that can help teams develop more precise estimates while encouraging collaboration. 

During planning poker, players will have a “hand” of options (a set of estimation values) to choose from. A team member who’s not participating in voting (for Agile teams, usually the product owner) selects a work item. In secret, everyone chooses the value they believe represents the item. Then everyone reveals their cards—their chosen value—simultaneously. Discussion follows when there are discrepancies. 

While in traditional poker you get a new hand each round, in planning poker you’ll keep the same hand throughout, displaying one card to represent your estimate for each work item in question. There are planning poker card decks that have estimation units such as T-shirt sizes and story points. 

During planning poker, the team seeks to reach an agreement about the estimate for a specific work item before they move on to the next item. If a team has been together for a while and they have a sense of their work, estimates often are fairly similar unless there are unexpected underlying assumptions, which planning poker helps to surface. For newer teams or cases where you’re estimating brand new work, there might be more variance in estimations from team members. 

This estimation technique helps to strengthen collaboration between team members, leading to productive discussions and improved estimates. Planning poker is most valuable for work that requires team discussion, rather than less complex well-understood tasks. This technique also works well for smaller teams or a smaller number of items within a backlog.

Affinity estimation

Affinity estimation helps teams quickly estimate the relative size and complexity of items in a backlog. This technique aims to streamline the estimation process, allowing people to tackle items faster and reduce cognitive load.

To facilitate affinity estimation, teams use a simple spectrum with the word “smaller” on one end and “larger” on the other, with space in between. This spectrum is typically put on a physical wall or a virtual whiteboard. Team members take each backlog item and place them along this continuum based on relative size, comparing each item to ones that have already been placed. Is an item smaller or larger than another item already on the spectrum? 

As more items are added, people can adjust previous ones to ensure that the relative sizing makes sense. Once the team is satisfied with the placement of work items, they have the option to assign estimation units, such as story points or T-shirt sizes, if needed. 

This visual approach keeps the estimation process lightweight and prevents teams from overanalyzing early on. By focusing on relative comparisons rather than absolute estimates, teams can rapidly size a large number of backlog items with ease. This technique is great for teams that have inherited a backlog or are starting a new project together. Affinity estimation provides rough estimates, but once you’ve ordered your backlog, you can then use a more detailed estimation technique for items that need further discussion.

Bucket system 

Bucket system estimation is another quick technique that helps teams size items in a large product backlog. Similar to affinity estimation, with the bucket system, you divide work items into “buckets” based on complexity. 

A facilitator starts by numbering different buckets using the Fibonacci sequence. It’s important to establish the buckets first, before doing any estimating. Then, the team selects a work item and decides which bucket to place it under. Based on the team’s understanding of complexity relative to that first work item, each item within the backlog is selected and placed into buckets until all items have been sized. 

The key is to make sure that everyone agrees before final estimates are set. Items should also be evenly distributed and not all within one bucket. This system is very helpful when a large backlog needs to be sized quickly. The bucket system is also useful for teams working remotely as it’s easy to facilitate in a visual collaboration platform. 

Three-point system 

The three-point system considers best-case, worst-case, and most likely scenarios (also known as optimistic, pessimistic, and most likely values) in order to calculate an estimate. As an approach that accounts for more variability, this system aims to provide better-informed forecasts—especially since it’s easy for teams to fall into the trap of thinking that if they’ve done something before, they can do it faster the second time. 

To use the three-point estimation technique, ask your team: 

• If everything goes well, how long will this work item take? (optimistic value) 

• If you run into blockers, how long will it take? (pessimistic value) 

• Based on your answer to the first two questions, what’s most likely? (most likely value)

Then, one way to calculate the average is by adding up the values and dividing by three. Many teams also use a weighted formula in their calculations. 

By using the three-point system, teams can have conversations about potential challenges early on and manage those in advance. This method is highly useful for teams that prefer upfront discussions and more realistic estimates. However, the three-point method does require more time and effort than other techniques, especially when envisioning potential scenarios.

Another approach: NoEstimates

A challenge that many teams encounter with estimation is that there can be so many variables at play, making it feel impossible to accurately or realistically estimate the effort required for work items. In addition, sometimes estimation metrics can be misused and actually put more pressure on individuals to meet abstract expectations rather than focusing on delivering value, which impacts their quality of work or work-life balance.

For these reasons, there is a #NoEstimates movement within the Agile community that focuses on delivering value quickly and adapting to change rather than focusing on often inaccurate and time-consuming predictions. The NoEstimate approach aims to help teams eliminate a source of waste and enhance agility by focusing on delivering small pieces of value and getting feedback quickly.

NoEstimates is different from a structured estimation technique such as planning poker or affinity estimation. Instead, it’s more of an alternative approach or perspective. NoEstimates isn’t meant to avoid estimation but rather to shift to delivery metrics such as cycle time and throughput.

NoEstimates works best when teams are: 

• Taking on small, well-defined work items. 

• Willing to shift their focus from forecasting work to optimizing flow and cycle time.

• Aiming to deliver small items quickly. 

• Tracking a stable workflow where they can measure actual throughput instead of estimated effort.

How to choose the best Agile estimation techniques

Now that you’re familiar with some of the most common estimation techniques, how do you begin to choose which one to try? The right approach depends on factors like the type of work, team preferences, and how much detail is needed. 

Consider these factors when choosing an estimation approach:

1. The size and scope of work you’re estimating. If you’re estimating smaller work items or a handful of (well-defined) tasks, techniques like planning poker and units like story points can help teams estimate sufficiently in a short amount of time. For larger items, or even epics, T-shirt sizing and the bucket system can help you categorize bigger chunks of work without excessive detail. 

2. The clarity of the work being estimated. Sometimes, an item can be too vague to estimate. This means the item needs further refinement. Take time to break down the item even more (a technique known as “story splitting”), or do more research before you commit. 

3. Your team’s collaboration styles. Yes, there are different collaboration styles, and this can be a huge factor in team estimation. Not everyone likes live activities or sharing their ideas out loud. Taking the time to understand your team’s collaboration styles can help you determine which technique matches the best for your circumstance.

4. Historical insights. Conducting estimation techniques is one thing—documenting the results is another. It helps to use a tool such as a visual collaboration platform to keep a historical record of your estimation sessions and team discussions. This way, you can use relative sizing (more on this below) and view past estimations to iterate and improve your estimation techniques. 

5. Matching technique complexity to your team’s needs. Some estimation techniques (such as planning poker) work best for smaller teams. Other techniques are great for software development teams, while others (such as T-shirt sizing) are great for marketing teams estimating large-scale campaigns. Take some time to determine your team’s needs and the desired results of estimation before you jump in. 

Remember, estimation isn’t about predicting the future perfectly, but gaining shared understanding and making informed decisions together. The best estimation technique for your team is the technique that helps everyone move forward with confidence and alignment. 

Tips on improving your Agile estimation techniques

“When your team is able to effectively estimate the amount of time or effort it takes to bring a work item to completion, this ever-evolving process informs future estimates, fueling continuous improvement.” 

—Bryan Stallings, chief evangelist, Lucid 

No matter which estimation technique you decide to try, here are a few ways you can refine your process over time: 

• Involve the whole team. Estimation isn’t an individual process; everyone who contributes to the work should weigh in. Involving the entire team helps to uncover hidden complexities, enhance knowledge, and increase buy-in. Open dialogue during estimation also improves team collaboration. 

• Embrace relative sizing. Estimating based on relative complexity (comparing a new work item to one that’s been already completed) is more accurate than trying to assign an absolute number. Keep a few benchmark or touchstone work items on hand to help quickly place new items in context. Similarly, leveraging past data and tracking previous completions offers evidence of how much your team can achieve. Tracking past completed work, often called “yesterday’s weather,” helps teams estimate more accurately by using real historical data.

• Avoid overcommitting. Estimates that are overly optimistic can lead to stress, reduced quality, and burnout. Encourage a culture of realistic planning. Once you’ve established a sustainable pace, use that as a guide to prioritize work based on value, urgency, and feasibility.

• Use consistent units of estimation. Shifting from one unit or value to another (such as using T-shirt sizes and then using story points) can cause confusion and inconsistency. Pick your estimation metric and stick with it for at least a few sprints so you can gather meaningful data.  

• Timebox estimation activities and discussions. Long, meandering estimation sessions drain energy and can frustrate teams. Focus the discussion by timeboxing estimation. If more discussion is needed, set the item aside for backlog refinement or schedule a separate session to come back to things. 

• Foster a safe environment for disagreement. When your team feels safe to have an honest debate and are free to disagree or dissent, this uncovers overlooked complexities. By getting everyone’s feedback, you can dig into the assumptions behind estimates—especially if the estimates vary widely. Often, the best discoveries happen in these honest discussions.

• Revisit estimates during retrospectives. Estimates that you’ve made in the past might not reflect your current reality; understanding, requirements, and variables evolve. Adjust estimates during backlog refinement and conduct retrospectives so you can adapt your estimation for continuous improvement. 

Use a visual collaboration platform for your estimation techniques

Estimation techniques are highly beneficial for any team that’s seeking to become more agile and efficient. Conducting estimation with your team helps everyone align, collaborate, and prevent burnout—and it makes your team better prepared for complexity and change. 

Using a visual collaboration platform like Lucid can not only help you facilitate estimation sessions but it also keeps a record of your estimations so you can continually improve. Check out Lucid’s Agile solutions for templates, resources, and more to successfully implement Agile estimation techniques and other common Agile practices for your team.