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:
What is agile estimation?
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.
Why do agile teams estimate?
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.
To gain shared understanding
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.
To make plans
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.
To set priorities
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:
- Item A would double your product’s sales once finished
- Item B would increase revenue by 10%.
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.
To practice Scrum 🌶
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.
The Scrum Guide 2020 edition
“Product Backlog refinement is the act of breaking down and further defining Product Backlog items into smaller more precise items. This is an ongoing activity to add details, such as a description, order, and size. The Developers who will be doing the work are responsible for the sizing.”
To answer stakeholders
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.
How does agile estimation work?
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.
Agile estimation methods
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.
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.
Three Point Method
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
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.
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:
- They break down all their stories into similarly small units.
- They track the average number of stories they completed in previous sprints or cycles.
- They assume they’ll complete a similar number in the next iteration.
- They plan and prioritize by taking the most important story from a requirements doc or backlog. They then work on that item without estimating or refining others. Once done, they take the next most important one, and so on.
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.
Agile estimation units and scales
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:
- Time. Used when teams estimate work in hours or days.
- Story points. Numbers that express the size of a piece of work compared to other pieces of work and that factor in aspects like effort, risk, and complexity.
- Proxies. Objects representing an item’s size, like different-sized t-shirts, vehicles, or cute animals.
💡 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:
Agile estimation metrics
“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:
- Sprint velocity is the number of story points a team completes in one sprint. They can use this metric to predict or limit how much work to take on in their next sprint.
- Cycle time measures the time it takes to complete tasks. It tracks how long items spend in their Kanban or Sprint board’s “in progress” stage. You can use cycle time to find bottlenecks and inform stakeholders without giving specific completion dates (“On average, it takes us 15 days to complete an item once we’ve started working on it.”).
- Throughput expresses the number of items (instead of story points) a team completes per sprint. Experienced teams adept at splitting their stories into similar sizes can use this metric. By doing so, they can stop estimating story points and simply measure throughput to understand how much work they can expect to complete in future sprints.
💡 For details on these and other agile metrics, head to The 10 Most Helpful Agile Metrics According to Experts.
Risks of estimation
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:
- Conflating estimates with commitments. Estimating and committing are not the same thing. Treating estimates as commitments can cause people to stop giving their best estimate and instead “sandbag” by adding lots of slack to their numbers, which makes them unreliable.
- Creating pressure with unrealistic estimates. When teams or their managers don’t adjust unrealistic estimates but hold on to them as goals, the numbers can quickly pressure the team and lead to overwork and shortcuts that affect quality.
- Falling prone to biases when estimating. Cognitive bias, groupthink, optimism, pessimism and even our evolutionary development, all lead us to make errors when estimating. Sprint Poker can help you prevent groupthink and anchoring with anonymous estimation.
- Mistaking planning for action. Estimating and planning can make teams feel productive so they may end up spending too much time on it. As an Agile practitioner we spoke to said: “I sometimes wonder how much time is wasted estimating something instead of working on it.”
If anything, remember that no matter what we do, we can’t control the future, and estimates are just that – estimates.
Oliver Burkeman in Four Thousand Weeks
“We treat our plans as though they are a lasso, thrown from the present around the future, in order to bring it under our command. But all a plan is—all it could ever possibly be—is a present-moment statement of intent. It’s an expression of your current thoughts about how you’d ideally like to deploy your modest influence over the future. The future, of course, is under no obligation to comply.”
Agile estimation FAQs
Parabol’s answers to some of the most frequently answered questions about agile estimation.
How do you estimate tasks in agile?
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.
What’s the difference between relative estimation vs. absolute estimation?
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.
What’s the difference between estimating and forecasting?
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.