Agile Estimation: A Guide to Efficient Planning & Delivery

Agile estimation should be a helpful process that aligns teams and makes work easier. Yet you may often find yourself staring at a task, or lost in discussion with teammates, wondering why estimation feels like such a complex puzzle. Is it worth the effort? Can you ever get your estimates right? Is there a better way?

When done right, agile estimates aren’t on or off. They’re rough indicators for your team of how much work a story or task might involve. You use them to plan work, make decisions, and encourage transparency.

By the end of this article, you’ll know how to turn agile estimation from waste into a valuable activity that enables collaboration, planning, and problem-solving. Here’s what we will cover:

Agile estimation is the process of quickly predicting the amount of work involved to complete a task (also known in Agile circles as user stories). All team members work together to make estimates, and estimation techniques like T-Shirt Sizing and Planning Poker help them get sufficiently accurate results without wasting time. The goal of agile estimation is to align your team on how much effort a task will require to complete so you can plan better. 

Agile estimates consider factors like effort, risk, and complexity – not just how long something will take. They’re usually relative, meaning teams arrive at them by comparing stories or tasks to each other.

Say we’re comparing shoes. You can’t tell the exact size of a shoe just by looking at it. That would require more effort and a tape measure. But you can see whether one shoe is about double the size of another. That’s exactly what teams do during agile estimation, and it’s usually good enough for their needs, since estimates don’t need to be 100% accurate.

Agile teams estimate to improve team alignment, better understand tasks, work together more effectively, and improve planning. The goal of agile estimation isn’t precision but acceptable accuracy for plans, decisions, and discussions.

Many teams like to estimate for the conversations the process sparks. Those conversations are more important than deciding on an abstract estimate.

When a team looks at something together and decides what it is, they gain shared understanding. If estimates vary significantly between team members, this can trigger questions and discussions. Disagreement signals that an item requires more attention to uncover complexity, uncertainty, or risk.

Collaboration requires planning. When two or more people want to pursue a goal together, they must agree on who will do what and, usually, by when.

Is the what big or small? Does it require coding or design? When is the coding ready so the design can start? By when can the customer use it?

Plans vary in size. Some are as small as a quick chat between two people. Others are multi-month efforts, like when a team of hundreds prepares to build a skyscraper.

Whatever the size of the plan, you need to estimate the work involved. A Scrum team has to decide how much work to include in a sprint. Sales need to price what they sell. Project managers need timelines for stakeholders.

Estimates drive planning, helping teams align, overcome obstacles, and achieve success.

It’s hard to prioritize tasks without estimates. The expected time or effort required to complete something usually plays an essential role in deciding whether to work on it now, later, or not at all.

Imagine you have two items you could work on next: 

The catch? Item A takes six months to complete and Item B takes only one week, so you’d probably prioritize item B.

This example is extreme, but it shows that prioritizing without estimates is difficult, if not impossible. And such prioritization happens everywhere, all the time, whether it’s executives setting company strategy for the coming year or an individual choosing which item from their to-do list they’ll work on next.

While the latest Scrum Guide doesn’t include the word “estimate”, and estimation or planning poker are not one of the official Scrum events, some form of estimation often happens in many Scrum teams.

The guide emphasizes that teams need to know how much work they can complete in a sprint. It also mentions “sizing”, which is a form of estimation.

In Applying Scrum With Kanban, author and agile trainer Andy Hiles highlights three questions stakeholders often ask:

1. “When can I get that thing?”
2. “When can I get all of those things?”
3. “How many things can I get by this date?”

Without estimates, such answers are hard to give. But remember that estimates are imprecise and subject to change as more data is available. So be wary of giving hard commitments.

Instead, consider giving a probability estimate that leaves some wriggle room for unexpected hiccups or complexity.

💡 Struggling to manage the demands of stakeholders? Discover how to manage them better in 8 Agile Estimation Techniques to Try With your Team.

Agile teams estimate at the beginning of a sprint during Sprint Planning or as part of a separate backlog refinement process. Some Scrum teams use their estimates to monitor progress towards the Sprint Goal during the Daily Scrum.

There are many ways to make estimation efficient and effective, such as Planning Poker, T-Shirt Sizing, or using a scale like the Fibonacci sequence. Regardless of your methods or tools, all team members should participate in estimation, with the development team – not the Product Owner or Scrum Master – giving the final estimates.

💡 Check out The Product Owner’s Guide to Better Sprint Planning for more details on preparing and running such a meeting.

The purpose of estimating is always the same, no matter which method you use. But the approach you choose can lead to different types of discussions and outcomes, which is why it’s helpful to understand when to use each method.

Here are some popular estimation methods you could try with your team:

T-Shirt Sizing is a high-level approach in which you use t-shirt sizes (XS, S, M, L, and XL) to assign rough estimates to user stories. It’s one of the simplest estimation methods because the scale is clear and understandable to everyone.

When to use it: T-Shirt Sizing is helpful when you need to quickly filter out stories that are too large so that you can break them down further.

👉️ Try this activity in Parabol

Sprint Poker, also known as Planning Poker, lets teams estimate with precision, encouraging nuanced conversations. This technique prevents anchoring and gives you a number you can convert into hours, should you wish to, unlike with T-Shirt Sizing.

In Planning Poker, each participant estimates the amount of effort a task will involve by playing cards with different values from a customized deck. After everyone plays their cards, a discussion follows of the estimates, so the team aligns about the effort required to complete pieces of work.

When to use it: Sprint Poker is effective for discussing a limited number of stories in detail and prevents biases such as anchoring and groupthink.

👉️ Try Sprint Poker in Parabol

The three-point method involves creating three estimates for each work item based on three different scenarios: best-case, worst-case, and most likely. Combining these estimates allows you to calculate a more accurate estimate for the story or task.

When to use it: The Three Point Method helps teams perform a mini pre-mortem on their sprint by considering best-case and worst-case scenarios in advance. The approach also works well if you tend to be overly optimistic.

Big, Small, Uncertain focuses your estimation efforts on the most pressing items to discuss: the uncertain ones.

You earmark large items for future estimation sessions. Small ones are easy to estimate and don’t need much discussion. And with those out of the way, you leave plenty of time to talk about the remaining uncertain items.

When to use it: Try Big, Small, Uncertain when you need to estimate many stories but want to concentrate on areas where the team lacks clarity or experience, such as when facing technical complexity or unclear requirements.

Weighted Shortest Job First (WSJF) helps teams prioritize tasks based on the value they provide relative to their size. You calculate A WSJF estimate by dividing the item’s size by its importance, also known as the Cost of Delay (CoD).

By the end of a WSJF estimation session, you’ll have a backlog prioritized by tasks that will deliver the maximum economic benefit: higher priority items that are easiest to complete at the top and heavier, lower value ones near the bottom.

When to use it: WSJF originates from the Scaled Agile Framework (SAFe). It’s helpful for product development teams that want to make a business impact quickly.

👉️ Try this activity in Parabol

The #NoEstimates movement advocates for avoiding estimates entirely. They believe that estimating is waste because most modern work is unpredictable. Nevertheless, teams that follow the #NoEstimates approach still do some estimation and planning, as they usually implement some of these practices:

When to use it: Small teams with few internal and external dependencies – and a willing client – can benefit from the #NoEstimates approach. You’ll still get a pretty accurate picture of what you can expect to finish each sprint or iteration while saving some time on estimating and planning.

💡 Head over to 8 Agile Estimation Techniques to Try With your Team for more techniques and more details on each one.

Estimation units and scales measure and express a work item’s size, effort, risk, or complexity. When teams use them consistently, their estimates become more accurate, and they reduce the chance of misunderstandings.

There are three types of units agile teams use for making estimates:

💡 Confused about story points? Who isn’t! Turn to our complete guide on story points to find answers on every question you might have about this topic.

Using alternative scales instead of the standard 1, 2, 3, 4, etc., can speed up the estimation process, especially for larger and more complex tasks.

Suppose your team needs to estimate the effort required for a big item, such as adding a new feature to your app. If you use a standard scale and discuss the task with your team members, one picks 31, another 36, and a third 38. Even though the differences between their estimates are minor, they could lead to extended discussions.

An alternative scale like the Fibonacci sequence prevents this issue because you have to choose from numbers with a wider distance between them. In this example of our app’s new feature, everyone would likely pick number 34, as the alternatives would be 21 or 55.

Some popular estimation scales include:

“Not everything that can be counted counts, and not everything that counts can be counted.” – often misattributed to Albert Einstein

An agile metric is a number that informs the team about the status or performance of an outcome that’s important to them.

There are three agile metrics teams might use in their estimation process:

💡 For details on these and other agile metrics, head to The 10 Most Helpful Agile Metrics According to Experts.

Estimations aren’t always great. They can cause frustration and friction through forced commitments, unrealistic expectations, or biased assumptions. 

So keep these risks in mind when you work with agile estimations:

If anything, remember that no matter what we do, we can’t control the future, and estimates are just that – estimates.

Parabol’s answers to some of the most frequently answered questions about agile estimation.

The easiest way to estimate tasks in agile is to use special estimation techniques that prioritize speed and acceptable accuracy over precision. Popular methods include T-Shirt Sizing, Planning Poker, and the Three-Point Estimation Method. These approaches quickly give teams sufficiently accurate estimates for plans, decisions, and discussions.

For example, with T-Shirt Sizing, teams assign task sizes such as XS, S, M, L, or XL by comparing items to each other based on their relative complexity or required effort. Team members then discuss tasks where their estimates differ to determine the final size for each item.

Relative estimation compares work items to one another, whereas absolute estimation tries to determine a specific and independent value for a work item. Agile teams typically use relative estimation because it’s faster and more effective for planning and discussions. Absolute estimation, on the other hand, requires more effort and is less flexible.

Estimating relies more on judgment and forecasting more on data.

When estimating, you predict a project or task’s duration, effort, or cost based on available information and past experience. This approach involves breaking down the project or task into smaller parts, making assumptions, and using historical data or expert judgment to develop a reasonable estimate.

Forecasting means predicting future outcomes or trends based on data and statistical models. It requires analyzing trends and patterns in data, identifying key drivers of change, and projecting future results based on these factors.