12 Agile Estimation Techniques to Try With your Team

“If the only tool you have is T-Shirt Sizing, every backlog looks like a wardrobe.” This quote highlights the challenge you face after mastering the basics of agile estimation: you know why to estimate, you know what to estimate, but your how is too limited – you lack a range of agile estimation techniques for different situations.

This article explores 12 agile estimation techniques, from popular ones like T-Shirt Sizing and Sprint Poker to lesser-known methods like Bucket System Estimation and Random Distribution:

We’ll compare the different approaches and provide guidelines so you can select the most appropriate one for your needs. By the end, you’ll know how they work and when to use them.

💡 Need a primer or refresher on the basics of agile estimation?.

Suitable for: New teams, large backlogs, or early-stage estimation.

T-Shirt Sizing is a fun agile estimation technique that helps your team get a rough estimate of a task quickly. It’s particularly useful for finding large user stories that need further breakdown or selecting from already sizable projects.

To start with t-shirt size estimation, the Product Owner reads out a story and asks team members to estimate how much effort it will take. You express this with a scale of t-shirt sizes like XS, S, M, L, and XL. You can even add XXL to root out those pesky epics masquerading as stories.

For unbiased T-Shirt Sizing, teams can use a blind estimation process. You privately pick your estimate to prevent influencing others. Once everyone has made their choice, reveal your estimates simultaneously. This approach fosters diversity of thought and helps prevent the risk of groupthink or conformity.

Fun tip: Why limit yourself to t-shirts? Nobody stops you from turning t-shirts into dogs or food. Say you’re into exotic fruits, like us – try using strawberries 🍓, kiwis 🥝, oranges 🍊, coconuts 🥥, and watermelons 🍉 to estimate the relative size of your stories.

When to use it: T-Shirt Sizing excels at sparking team collaboration, creativity, and fun! It’s ideal for new teams, large backlogs, or early-stage estimation. Just remember to follow up with a more accurate technique, like actual hours, when you need more precise estimates.

Suitable for: Established teams, prioritized backlogs, or late-stage estimation.

Sprint Poker – or Planning Poker – is a fun and effective agile estimation process that helps teams arrive at more precise estimates. It’s a gamified technique that reduces the cognitive bias of anchoring and encourages conversations among team members.

In Sprint Poker, each team member has a set of cards. Like in real poker, you keep your cards hidden. Each card has a scale of numbers. After reading a user story out loud, the Product Owner asks the team to reveal their chosen estimate by showing one of their cards. With Parabol’s Sprint Poker teams can do this easily in a remote work setting.

The value of the card you select should correspond to the effort the story will take. The numbers on the cards may be absolute (hours) or abstract (story points). Popular scales include Fibonacci, Modified Fibonacci, actual hours, powers of two, and playing cards.

Upon revealing your cards, everyone has likely chosen different values. These differences prompt discussions about the varying numbers, allowing the team to share insights and reach a more accurate estimate.

Joe may know something about the product infrastructure you weren’t aware of. Maybe Anna didn’t factor in the additional QA testing needed to ship that feature.

Going through this process also helps develop a mutual understanding that improves future estimations.

When to use it: Sprint Poker is perfect for teams with specific stories they want to discuss in detail. It suits any group but works exceptionally well with established teams that already understand each other’s perspectives and knowledge, and teams that work remotely. This technique provides a defined estimate number that can be converted into hours if you want to.

Try Sprint Poker in Parabol to minimize bias and strengthen shared context among your team members.

Suitable for: All experience levels, prioritized backlogs, or late-stage estimation

The Three-Point Method considers the best-case, worst-case, and most-likely scenarios to produce a more nuanced estimate. By using this method, teams have early conversations about potential challenges and address them in advance during the refinement process.

To use the Three-Point Method, ask your team:

Once you have the answers, calculate the average using either the triangular averages method, which gives equal weight to each value, or the beta distributions approach, which provides more weight to the most likely value. The beta methodology is more precise because it follows the typical distribution curve.

When to use it: The Three-Point Method is ideal for teams who want upfront discussions about various scenarios and strive for realistic estimates rather than aspirational ones. It works well for both new and experienced teams.

⚠️ The Three-Point Method requires much upfront work, especially if you’re estimating a large backlog. It can also be challenging for managers who have trouble envisioning multiple scenarios.

Suitable for: New teams, large backlogs, or early-stage estimation.

Overwhelmed by a massive product backlog? Struggling to estimate stories individually? Affinity Estimation is here to help. This technique simplifies the estimation process, allowing teams to reduce cognitive load and tackle more user stories faster.

Here’s how it works: The Product Owner starts by reading the first story and asks the team to set an estimate using any preferred scale as a base. Let’s say the team agrees on an 8. When the Product Owner reads the next story, the team’s task is to compare it to the first. Is it larger or smaller than the 8 already identified?

If team members have differing opinions, encourage open discussions. Ask them to explain their reasoning and use that conversation to reach a consensus. This practice helps refine estimates and creates a shared understanding among team members.

Here’s an example of what such a conversation might look like:

After assessing all stories in this way, decide on the next steps. Perhaps smaller items are good to go, and you want to focus on estimating larger ones in more detail.

When to use it: Affinity Estimation is ideal for blitzing through a large, un-estimated backlog. It’s perfect for new teams inheriting a backlog or starting a new project. Affinity Estimation helps you sort items and arrive at rough estimates. Once you’ve prioritized the backlog, apply a more precise estimation technique to critical items.

Suitable for: Large backlogs, early-stage estimation, and collaborative prioritization.

If you struggle to balance precision and speed in agile estimation, consider using Relative Mass Evaluation (RME), also known as the Ordering Protocol. This technique considers all your user stories and estimates their mass relative to one another instead of comparing just two items at a time, as with Affinity Estimation.

Here’s how to implement RME: Start by laying a scale on a table. The Product Owner reads each user story aloud and asks the team to place them somewhere on the scale according to their relative mass.

This method is highly collaborative, as team members can move items around on the scale, refining their estimates throughout the session. With RME, you don’t have to assign a specific number of hours to each story–unless you want to, of course!

When to use it: Choose Relative Mass Evaluation when you have numerous items to evaluate in a limited timeframe. It offers a quick method for assessing the relative effort required for each user story.

Suitable for: Established teams or large backlogs.

Dot Voting is a fun and straightforward way to estimate user stories, and is often used in retrospectives as well. This technique allows teams to express effort quickly and visually, making it an efficient way to get through numerous items in a limited time.

To use Dot Voting:

The process is simple: more dots on a story indicate higher effort, while fewer dots suggest less effort. This method lets you easily spot patterns on a whiteboard and quickly work through many items.

Dot Voting has its drawbacks. It can be prone to cognitive bias, such as anchoring. When everyone sees dots appearing, groupthink can take hold. To counter this, hide votes initially, then reveal them simultaneously. Doing so improves the accuracy of your estimates.

When to use it: Dot voting is great for experienced teams that have worked together for a while. It’s an enjoyable and easy way to estimate user stories, especially when you have a physical or virtual whiteboard.

Suitable for: Established teams, large backlogs, or early-stage estimation.

The Maximum Allowable Size (MAS) estimation technique helps you break down large items in the backlog, much like sifting flour to remove lumps for a smooth cake mixture. MAS identifies epics and big ideas you need to downsize into more manageable stories.

To use MAS, first pick an estimation scale, such as hours, story points, or t-shirt sizes. Then set a limit, for example, that user stories can’t exceed 16 hours.

Review all items in the backlog and filter out those the team believes will surpass the maximum allowable size–accomplish this through voting. Finally, discuss the oversized items and decide how to split them into smaller stories below the threshold.

When to use it: Use MAS when your team struggles to finish tasks during a sprint or needs to address large, unwieldy items at the bottom of the backlog. A MAS review ensures items are the right size for the Sprint Backlog.

Suitable for: New teams or early-stage estimation.

Embrace simplicity with the Big, Uncertain, Small estimation technique. The Big, Uncertain, Small, method quickly narrows down items that warrant discussion and decision-making.

You set small items aside without further conversation, while oversized items are flagged for in-depth estimation later. With these out of the way, your team can focus on discussing uncertain stories.

This technique allows team members to recognize their uncertainty about whether a task is big or small. Uncertainty could signal the item falls in the middle or areas where the team lacks skills, knowledge, or experience.

Engage in open discussions about uncertain user stories to address:

After discussing uncertainties, reevaluate the user story and classify it as big or small.

When to use it: Big, Uncertain, Small is perfect for quickly estimating a large backlog and focusing on areas where you lack context. It’s also suitable for newly-formed teams without much prior data.

Suitable for: SAFe environments, prioritizing value, and focusing on efficiency.

Weighted Shortest Job First (WSJF) is a lightweight, agile estimation technique that helps teams identify high-value, small-sized tasks.

Developed by management expert Don Reinertsen and popularized by Scaled Agile Framework (SAFe) creator Dean Leffingwell, WSJF uses the Cost of Delay (CoD) and job size to prioritize your backlog.

To use WSJF, follow these steps:

WSJF is helpful for product development teams aiming to make an immediate business impact. Keep in mind that estimating each item’s importance can be challenging and time-consuming. Managers might also struggle to grasp CoD and how to calculate it.

When to use it: WSJF helps teams prioritize work, maximize productivity, and quickly impact the business.

Suitable for: Complex backlogs, large backlogs, and new agile teams.

Bucket System Estimation is a simple and effective technique for sizing several items. You can quickly and efficiently sort through a big backlog by dividing stories into “buckets” based on complexity.

Start by numbering the different buckets sequentially using the Fibonacci sequence (0, 1, 2, 3, 4, 5, 8, 13, 20, 30, 50, 100, and 200), and then proceed with the following steps:

When to use it: Choose Bucket System Estimation when you need to size a large backlog quickly. It’s also ideal for newly-formed teams or when working on long-term projects where complexity may increase over time.

Suitable for: Advanced teams that use story point estimation and track velocity.

Story Counting is an advanced agile estimation technique that focuses on tallying the number of user stories your team can complete within a sprint. Instead of using story points to measure story sizes, Story Counting assumes that small and large items will even out over time, making it sufficient to estimate, track, and plan the number of stories.

To use Story Counting effectively, ensure your user stories are within the same effort range, say one to eight points. Once you’ve grouped your user stories into the appropriate effort range, follow these steps:

While story points help identify poorly understood stories, Story Counting relies on your team’s ability to recognize stories with hidden complexities. It is crucial to maintain a mechanism to spot these stories and break them down into manageable chunks.

When to use it: Story Counting works well for advanced teams with experience in Agile estimation and velocity tracking. It’s a good alternative if you use story points but want to simplify your estimation process.

⚠️ Story Counting doesn’t replace the need for relative sizing–accurately understanding the size and complexity of stories in your backlog remains essential.

Suitable for: Small teams with few dependencies and clients open to flexible delivery.

The #NoEstimates movement questions the need for traditional estimation, arguing that it leads to waste due to the unpredictable nature of modern work.

Nevertheless, teams adopting the #NoEstimates approach still engage in some estimation and planning by following one or more of the following practices:

In essence, #NoEstimates simplifies the estimation process by reducing the range of possible estimates to two options: tasks that fit within a sprint and those that do not.

By breaking down the most critical user stories into smaller tasks and executing them efficiently, teams can demonstrate progress and value to clients. This approach can make clients less concerned with estimates and more willing to let the development team continue working through the backlog.

While the #NoEstimates approach might save you some time, the risk is losing an opportunity for discussion. When a team looks at something together and decides what it is, they gain shared understanding. Disagreement signals that an item requires more attention to uncover complexity, uncertainty, or risk.

When to use it: The #NoEstimates approach best suits small teams with minimal internal and external dependencies and clients open to flexible delivery. The technique helps shift the focus from timelines and estimates toward delivering value. #NoEstimates can also help protect Scrum teams from organizations that obsess over velocity.

Let’s give a shout out to six lesser-known methods that bring an interesting or valuable twist to the estimation process.

“Ah, the perfect day!” Ideal Days reflect how long a task would take on working days with zero interruptions, distractions, or setbacks.

This approach is useful for teams and organizations that prefer a time-based estimation method and want to make sure everyone calculates their estimate in the same way. Just keep in mind that reality might have other plans. 😊

User story splitting breaks down large user stories into smaller, more manageable items. This approach makes tasks easier to understand and estimate. User story splitting is particularly useful when dealing with complex or extensive features that may be difficult to estimate as a whole or when items exceed a team’s established threshold, like a maximum of one sprint or day.

Random Distribution, also known as an ordering protocol, is a collaborative estimation technique in which you order items from low to high based on complexity or effort.

Start by placing all stories randomly in a list. Each team member then takes a turn choosing one of the following actions:

Continue taking turns until everyone passes, signaling you’ve reached a consensus.

The Random Distribution technique can prevent teams from getting bogged down in assigning specific size estimates. This approach streamlines the estimation process while promoting collaboration and a shared understanding of the project’s scope.

Magic Estimation is a collaborative, quick, and engaging estimation technique that encourages team members to rely on their intuition. In this method, you randomly distribute user stories to team members, who then assign estimates to each item without discussing their thoughts.

After this, team members can adjust estimates for stories they disagree with by moving them around on a board or writing a different value on a card in a different color. The facilitator removes items with no disagreement or minor differences and considers them estimated.

Repeat this process as many times as needed. Typically, after three rounds, a few items remain, which you then discuss as a group to reach a final estimate.

This technique is handy for teams looking to quickly estimate many user stories while still promoting collaboration and engagement.

The Wideband Delphi method is ideal for complex tasks that require expert judgment. These experts can be team members or external specialists or advisors you bring in for the occasion.

First, the experts anonymously estimate items, then discuss their reasoning, and finally revise their numbers until they reach a consensus.

Wideband Delphi is unique in its focus on leveraging the collective wisdom of experts to handle uncertainty. Choose it when a task is complex, has many unknowns, or when you expect differing opinions among specialists. This method combines diverse perspectives into a more accurate estimate and fosters a deeper understanding of tasks.

Probabilistic forecasting uses historical data to predict the likelihood that tasks will complete within specific time frames. Instead of relying on the team’s judgment, you analyze past completion times to inform predictions and answer stakeholder questions.

For example, the data might show you complete 50% of work items within two days and 85% within three days. With this knowledge, you can give probabilistic forecasts–or SLEs (Service Level Expectations)–to stakeholders: “There’s a 50% chance of finishing this task in two days and an 85% likelihood we will do it in three.” This Service Level Expectation (SLE) approach offers a more accurate and realistic way to communicate timelines and set expectations.

Probabilistic Forecasting uses continuous forecasting to manage uncertainties and provide stakeholders with up-to-date, accurate predictions. This method is particularly valuable for large projects with many unknowns, when past performance data is available, or when you want to avoid giving specific dates to stakeholders.

Scrum Masters frequently switch up the meeting templates used during Retrospectives to keep the process engaging and elicit different responses. The same concept applies to estimation.

Tailor your estimation technique according to the types of conversations you want to encourage. For example:

The most effective way to discover the right approach is to experiment. Use our helpful table as a starting point.

Don’t be afraid to experiment with various agile estimation techniques. Embrace the learning process, and watch your team’s performance soar as you discover the ideal method for each situation you face.

Here’s a list of frequently asked questions about agile estimation techniques.

Relative sizing is an agile estimation technique in which team members compare the complexity, effort, or time required to complete different tasks or user stories. Instead of assigning absolute values or timeframes, they determine the relative size of each item compared to others.

This approach helps teams make more accurate estimations by focusing on the relationships between tasks, making it easier to identify which items are larger or smaller in comparison, and leading to a better understanding of the overall workload.

User story estimation techniques are methods used by agile teams to gauge the effort, complexity, and time required to complete user stories. Some popular user story estimation techniques include:

These techniques help teams estimate workloads more accurately and allocate resources more efficiently, leading to a smoother project development process.

“User story estimation techniques” and “agile estimation techniques” are often used interchangeably.

Agile estimation relies on using story points and the Fibonacci sequence, but they’re not methods themselves.

Story points are a unit of measurement–numbers that express the size of a piece of work compared to other pieces of work. They factor in aspects such as effort, risk, and complexity.

The Fibonacci sequence is an alternative scale that teams can use instead of the standard 1, 2, 3, 4, etc. Using such a scale can speed up the estimation process, particularly for larger and more complex tasks.

Affinity mapping is a brainstorming and organization technique where team members collaboratively group related ideas, requirements, or user stories on a visual workspace (such as a whiteboard or sticky notes). This process helps teams identify patterns, relationships, and dependencies between items.

Affinity sizing (also known as affinity estimation) is an agile estimation technique that builds on affinity mapping. After grouping related items, the team works together to assign each group relative sizes or effort levels (e.g., using T-shirt sizes or story points). This process allows teams to estimate the overall workload and allocate resources more effectively, ultimately improving project planning and execution.

While both methods involve grouping and organizing items, affinity mapping focuses on identifying relationships and categorizing. In contrast, affinity sizing specifically targets estimating the size or complexity of tasks.