Avi SiegelCo-Founder of Momentum. Formerly Product @ Klaviyo, Zaius (acquired by Optimizely), and Upscribe.
Table of Contents
Do not index
Do not index
In Agile development, the phrase "estimation is not a commitment" is a common refrain, but that doesn't render it meaningless. While Agile prioritizes adaptability over rigid, long-term plans, effective estimation remains a critical tool for forecasting, planning, and managing expectations. It’s the connective tissue between a product vision and the practical realities of a development cycle. Without a shared understanding of effort, teams struggle with sprint planning, product owners can't reliably forecast release timelines, and stakeholders are left in the dark.
The challenge isn't about finding a crystal ball to predict exact hours. Instead, it’s about fostering a collaborative process to align the team on the relative complexity of work. Good estimation facilitates crucial conversations, uncovers hidden assumptions, and helps identify dependencies early. It empowers teams to answer vital questions: Can we fit this work into the upcoming sprint? What’s the likely scope for our next release? Are we taking on too much risk?
This guide moves beyond theory to provide a practical roundup of the most effective agile estimation methods used by high-performing teams. We will break down eight distinct techniques, from the well-known Planning Poker to asynchronous-friendly alternatives. For each method, you'll find:
- A clear explanation of how it works.
- Actionable steps for implementation.
- Specific pros and cons to consider.
- Guidance on when to use each technique for maximum impact.
By the end, you'll have a comprehensive toolkit to select and apply the right estimation strategy for any context, improving your team's predictability and a stakeholder's confidence.
1. Planning Poker
Planning Poker, also known as Scrum Poker, is one of the most popular and gamified agile estimation methods. Popularized by Mike Cohn of Mountain Goat Software, it uses a consensus-based approach to estimate the effort required for development tasks or user stories. This technique is designed to foster collaboration and prevent cognitive biases, such as anchoring, where the first number spoken influences subsequent estimates.
How It Works
During a session, the product owner presents a user story, for example: "As a user, I want to reset my password via email." The team discusses the requirements—what forms are needed, what email service is used, what are the security considerations? Then, each team member privately selects a card from a deck that represents their estimate of the effort involved. These cards typically follow a modified Fibonacci sequence (e.g., 0, 1, 2, 3, 5, 8, 13, 20, 40, 100).
Once everyone has chosen a card, they reveal their estimates simultaneously. If a junior developer votes '3' and a senior developer votes '8', this signals a valuable discussion. The senior developer might explain, "This requires a database schema change and integration with a third-party email API, which adds complexity." This discussion uncovers different assumptions and leads to a more accurate, shared understanding. The team re-votes until they reach a consensus, perhaps agreeing on '5' story points.
When to Use Planning Poker
This method is highly effective for:
- New or complex projects: Where a shared understanding of the work is still developing.
- Cross-functional teams: It gives a voice to every role (developers, QA, designers), ensuring all aspects of the work are considered.
- Sprint planning meetings: To quickly and collaboratively estimate the product backlog before committing to a sprint.
For a deeper dive into the mechanics and best practices of this technique, you can explore specialized tools for Planning Poker that digitize the process.
To help you get started, this summary box highlights the core components of a successful Planning Poker session.
These key elements-the Fibonacci scale, short session times, and simultaneous reveal-work together to create a structured yet flexible environment for accurate, team-driven estimation.
Actionable Tips for Success
- Establish a Baseline: Before you start, agree on a simple, well-understood "baseline" story and assign it a value (e.g., "Updating the text on the contact page is a 2-point story"). Use this story as a reference point for all future estimations.
- Focus on Effort, Not Time: Remind the team to estimate the total effort, complexity, and risk involved, not the number of hours or days it will take. This prevents estimates from being tied to specific individuals' skill levels.
- Use the Two-Round Rule: If the team can't reach a consensus after two rounds of discussion and re-voting, consider taking the higher estimate or parking the story for further refinement. This keeps the meeting moving.
2. T-Shirt Sizing
T-Shirt Sizing is a quick and collaborative agile estimation method used to forecast effort at a high level. Instead of assigning numerical points, teams categorize work items into relative sizes, such as Extra Small (XS), Small (S), Medium (M), Large (L), and Extra Large (XL). This approach is perfect for early-stage planning when precise details are unavailable, allowing teams to quickly gauge the relative scale of tasks without getting bogged down in specifics.
How It Works
In a T-Shirt Sizing session, a product owner presents a list of features or epics to the team. For example, an e-commerce team might be looking at these features for the next quarter: 'Implement guest checkout,' 'Add a product recommendation engine,' and 'Fix a CSS bug on the login page.' The team discusses each one briefly. They might quickly agree the bug fix is an 'XS'. The guest checkout, requiring UI changes and backend logic, is an 'M'. The recommendation engine, involving new algorithms and machine learning, is clearly an 'L' or 'XL'.
The goal is not to achieve perfect accuracy but to create a rough order of magnitude and facilitate a shared understanding. The sizes can later be mapped to story points (e.g., XS=1, S=3, M=8, L=20) for more granular sprint planning, giving the product manager a quick way to forecast the quarter's scope.
When to Use T-Shirt Sizing
This method is highly effective for:
- Initial backlog grooming: When you have a large number of unestimated items and need a quick way to prioritize them.
- Roadmap and release planning: To get a high-level forecast of what can be accomplished in a quarter or release.
- Early-stage projects: When requirements are still vague and detailed estimation would be premature and inaccurate.
Actionable Tips for Success
- Define Clear Size Criteria: Before starting, create and agree upon clear definitions. For example:
XS= A trivial change one dev can do in <1 day.M= A standard feature requiring a few days of work from 1-2 devs.L= A complex feature involving multiple components or dependencies.
- Use Reference Stories: Anchor each size category with a well-understood reference story. When estimating a new item, the team can ask, "Is this bigger or smaller than our 'Implement social login' feature, which we called an 'M'?"
- Focus on Relativity: Emphasize that the goal is to compare items to each other, not to determine exact timelines. The conversation should center on "Is Feature A roughly twice the effort of Feature B?"
- Limit the Number of Sizes: Stick to 5-6 sizes (e.g., XS, S, M, L, XL, XXL) to keep decision-making simple and fast. Adding too many intermediate sizes defeats the purpose of this high-level technique.
3. Dot Voting (Multi-Voting)
Dot Voting, also known as multi-voting, is a straightforward, democratic technique used for collaborative decision-making and prioritization. While not a pure estimation method like others, it is one of the most effective agile estimation methods for quickly gauging a team's collective opinion on the relative priority, effort, or importance of a list of items. It provides a simple, visual way to narrow down options and build consensus.
How It Works
Imagine a team retrospective where members have generated several ideas for improvement: 'Improve CI/CD pipeline speed,' 'Refactor the old user module,' 'Create more unit tests,' and 'Automate deployment checks.' Each participant receives three dot stickers. They can place all three dots on 'Improve CI/CD pipeline speed' if they feel it's the most critical issue, or one dot on three different items.
Once everyone has voted, the items with the most dots are clearly identified as the team's top priorities. If 'Improve CI/CD pipeline speed' gets the most dots, it becomes the clear focus for the next sprint. This visual result sparks a focused discussion about why certain items received more votes, leading to a shared understanding and a clear path forward.
When to Use Dot Voting
This method is highly effective for:
- Prioritizing a large backlog: When you need to quickly identify the most valuable features for an upcoming release or sprint.
- Retrospectives: To decide which process improvement ideas the team should focus on next.
- Design Sprints and Workshops: Companies like Google and IBM use it to rapidly converge on key ideas or features after a brainstorming session.
By combining dot voting with other agile practices, teams can create a highly efficient workflow. For example, using it within a strictly scheduled meeting enhances focus. You can explore the value of structured meeting schedules to learn more about the timeboxing technique and how it complements rapid decision-making.
Actionable Tips for Success
- Limit the Dots: Give each person only 3-5 dots. Scarcity forces participants to make thoughtful choices rather than voting for everything. The number of dots should be about 20-30% of the total number of options.
- Use Different Colors: Assign different colored dots to represent different criteria. For example, use red dots for "highest value" and blue dots for "highest effort." An item with many red dots and few blue dots is a clear quick win.
- Encourage Discussion: Use the voting result as a conversation starter, not the final word. Ask "Why did 'Refactor the user module' get so few votes, even though we complain about it?" to uncover valuable insights.
- Consider Anonymous Voting: If team dynamics might lead to groupthink or influence from senior members, use a digital tool or a private voting method to ensure all opinions are weighed equally.
4. Affinity Estimation
Affinity Estimation is one of the fastest agile estimation methods, designed for sizing a large number of user stories in a short amount of time. Popularized by Dean Leffingwell and widely used within the Scaled Agile Framework (SAFe), this technique involves grouping stories into clusters of similar size or complexity rather than assigning individual numerical values from the start. It is a highly collaborative and visual process that leverages the team's collective intuition.
How It Works
The process begins with user stories written on physical cards. The team stands around a wall labeled "Smaller" on the left and "Larger" on the right. Members silently pick up cards, read them, and place them on the wall relative to other cards. For example, a card for "Change button color" is placed on the far left. "Integrate new payment gateway" is placed on the far right. A team member might move "Add social sharing links" to be closer to "Change button color" because they feel it's a similarly small task. This silent, kinesthetic activity continues until the cards form distinct clusters based on perceived effort.
Once movement slows down, the team discusses the groupings. "It looks like we have a group of small UI tweaks here, and a group of major backend integrations over here." They then assign T-shirt sizes (XS, S, M, L, XL) or Fibonacci numbers to each cluster, instantly estimating dozens of stories in minutes.
When to Use Affinity Estimation
This method is particularly powerful for:
- Large backlogs: When you need to estimate dozens or hundreds of stories quickly, such as during Program Increment (PI) planning.
- Initial project scoping: To get a high-level sense of the project's overall size without getting bogged down in detailed estimation.
- Quarterly planning sessions: Where the goal is to get a rough cut of a large volume of work.
For more information on how this technique fits into broader planning activities, you can get a more in-depth look at the essentials of sprint planning and its key components.
Actionable Tips for Success
- Start with Anchor Stories: Before starting, place a few well-understood stories of different known sizes on the board as "anchors." For example, place a known 2-point story on the left and a known 13-point story on the right to create a shared reference scale.
- Embrace the Silence: Enforce the "silent sorting" rule for the initial grouping phase. This prevents individuals from overly influencing others and allows for a faster, more intuitive process. The goal is to capture gut feel first, then discuss.
- Use Physical Cards: Whenever possible, use physical sticky notes or cards. The tactile act of moving items around a physical space can enhance collaboration and engagement.
- Review the Outliers: After the initial grouping, pay special attention to stories that were moved back and forth frequently or sit awkwardly between two groups. These are perfect candidates for a short discussion to clarify assumptions.
5. The Bucket System
The Bucket System is one of the most efficient agile estimation methods for quickly sizing a large number of user stories. This technique prioritizes speed and simplicity, making it ideal for high-level planning or initial backlog grooming. It involves sorting items into predefined “buckets,” each representing a specific effort size.
How It Works
First, you prepare physical or digital "buckets" labeled with Fibonacci numbers (0, 1, 2, 3, 5, 8, 13...). The facilitator reads a user story aloud, for instance, "As an admin, I want to export a user list to CSV." Team members then give a thumbs-up or point to the bucket they think it belongs in. If everyone points to the '3' bucket, the story is placed there and the team moves on.
If there's a major disagreement—some point to '2' while others point to '8'—it signals a misunderstanding. This triggers a brief, time-boxed discussion. "The '8' voters are considering the need to handle millions of users, which requires a background job. The '2' voters assumed a simple, direct export." After clarification, the team re-votes and reaches a consensus, likely moving the story to a '5' or '8' bucket.
When to Use The Bucket System
This method is highly effective for:
- Large-scale backlog estimation: When you need to estimate hundreds of items quickly before a big planning event.
- Initial project scoping: To get a rough order of magnitude for a new project or feature set.
- Backlog refinement sessions: It serves as a fast alternative to more time-consuming estimation techniques.
This approach is a powerful tool for initial sizing exercises, and you can learn more about how it fits into the broader picture by exploring techniques for an effective backlog grooming activity.
Actionable Tips for Success
- Establish Reference Stories: Before you begin, place one well-understood story into each bucket to serve as a clear reference point. For example, "The '2' bucket is for stories like 'Fixing a typo'." This anchors the team's understanding.
- Use a Facilitator: A dedicated facilitator is crucial to keep the process moving quickly, read stories clearly, manage discussions, and prevent the session from getting bogged down in details.
- Timebox Discussions: If there is disagreement, allow for a one-minute discussion. If a consensus isn't reached, place the item in the larger of the disputed buckets and move on. The goal is speed, not perfect accuracy.
- Keep Buckets Visible: Whether using a physical wall with sticky notes or a digital tool, ensure the buckets and their reference stories are clearly visible to everyone throughout the session.
6. Three-Point Estimation
Three-Point Estimation is one of the more analytical agile estimation methods, adapted from traditional project management techniques like PERT. It tackles uncertainty head-on by creating a range of estimates instead of a single value. This method provides a more realistic view of potential outcomes by considering the best-case, worst-case, and most-likely scenarios.
How It Works
For each user story, the team determines three distinct estimates. Let's take the story: "Integrate a third-party payment provider."
- Optimistic (O): The best-case scenario. "The provider's API documentation is perfect, and there are no integration hiccups. We can do it in 3 story points."
- Most Likely (M): The most realistic estimate. "There will probably be some minor issues with authentication or callbacks. It will likely take 5 story points."
- Pessimistic (P): The worst-case scenario. "The API is unreliable, their support is slow, and we run into major security hurdles. This could blow up to 13 story points."
These three points are then used to calculate a final estimate using a weighted average, typically the PERT formula: (O + 4M + P) / 6. In our example, this would be (3 + 4*5 + 13) / 6 = 36 / 6 = 6 story points. This calculated value is more robust because it accounts for potential risks.
When to Use Three-Point Estimation
This method is particularly valuable for:
Written by
Avi Siegel
Co-Founder of Momentum. Formerly Product @ Klaviyo, Zaius (acquired by Optimizely), and Upscribe.