“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.
1. T-Shirt Sizing: For fun and fast estimates 👕
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.
2. Sprint Poker: Minimize bias and boost precision 🃏
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.
3. Three-Point Method: Get precise with a range of estimates 🎲
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:
- How long/how much effort will this story take if everything goes well? (Optimistic value)
- How long/how much effort will it take if you run into blockers? (Pessimistic value)
- Based on that information, what’s most likely? (Most likely value)
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.
- Triangular averages weight each value equally: Estimate = (O+P+M)/3
- Beta distributions weight the most likely value: Estimate = (O+P+4M)/6
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.
4. Affinity Estimation: Group user stories for efficient estimation 🤝
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:
- 🧑💻 Joshua: “Last time, it took a long time to set up the sharing function, but we can use what we learned to do it more quickly this time. That’s why I think the estimate should be lower.”
- 👩💻 Charlotte: “That’s true. We have some inherited knowledge. But we need to build additional functionalities for this sharing function that we haven’t built before. We ran into some problems last time and might again, especially with testing. That’s why I think the estimate should be higher.”
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.
5. Relative Mass Evaluation: Balanced, big-picture prioritization ⚖️
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.
6. Dot voting: Express effort quickly and visually 🗳️
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:
- Set up your user stories visually and assign each team member a color.
- As a group, decide on a scale – say one to five – representing the effort required to complete each item.
- Ask everyone to add dots to the stories according to the chosen scale.
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.
7. Maximum allowable size (MAS): Identify epics early and break them down ⛔
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.
8. Big, Uncertain, Small: Quickly focus on what matters 🤔
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:
- Big unknowns preventing decision-making
- Data or information needed to clarify uncertainties.
- Missing context someone else could provide.
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.
9. Weighted Shortest Job First (WSJF): Prioritize efficiency in SAFe environments 🏋️♀️
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:
- Estimate a task’s size and relative importance based on urgency, user- or business value, risk, or return on investment.
- Calculate the WSJF estimate by dividing the job size by its importance.
- Order the backlog based on tasks that deliver the maximum economic benefit.
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.
10. Bucket System Estimation: Sort a complex backlog quickly and efficiently 🪣
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:
- Select a random item and let the team decide which bucket to place it under.
- Discuss the features and requirements of another user story, then place it in the appropriate bucket based on the team’s understanding.
- Repeat this process until you’ve sized all items.
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.
11. Story Counting: Count stories instead of points 📊
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:
- Calculate your team’s velocity (how many user stories your team has completed in previous sprints or time frames).
- Use this number to set the number of user stories your team can plan for their next sprint.
- Continuously track and adjust your team’s progress, considering any changes in team size, story complexity, or other factors affecting the team’s capacity.
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.
12. #NoEstimates: Embrace uncertainty and focus on delivering value 🚫
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:
- Breaking down all user stories into similarly small units.
- Tracking the average number of stories completed in previous sprints or cycles to predict how many they’ll finish in the next iteration (Story Counting).
- Selecting the most important story from a requirements document or backlog, then working on that item without estimating or refining others. Once done, they move on to the next most important one, and so on.
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.
🏆️ Honorable mentions
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
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:
- Move an item up or down one spot in the order.
- Discuss an item to clarify its complexity or effort.
- Pass their turn.
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.
Choosing the right agile estimation technique for your team
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 Three Point Method encourages team members to discuss best and worst-case scenarios, helping identify potential issues early. Consider using the Three Point Method if your team tends to be overly optimistic or frequently encounters unexpected blockers.
- Sprint Poker or Planning Poker offers a more refined scale for estimation, fostering nuanced conversations. Try it if your team requires greater precision in estimations.
- Big, Uncertain, Small initiates discussions about areas where the team lacks context for decision-making. Use this approach to jumpstart estimation conversations, especially for inexperienced teams or backlogs with rough edges.
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.
Agile estimation techniques FAQs
Here’s a list of frequently asked questions about agile estimation techniques.
What is relative sizing?
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.
What are user story estimation techniques?
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:
- Planning Poker: A consensus-based approach where team members use a deck of cards with pre-assigned values (e.g., the Fibonacci sequence) to vote on the effort required for a user story.
- T-Shirt Sizing: A relative estimation method that uses different “sizes” (XS, S, M, L, XL) to represent the effort needed for each user story.
- Dot Voting: A technique where team members place a specific number of dots (or “votes”) next to user stories to indicate their complexity. The stories with the most votes are considered the most complex.
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.
Are story points and the Fibonacci sequence agile estimation methods?
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.
What’s the difference between affinity mapping and affinity sizing?
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.