Estimation in Agile Teams: Points, Poker, Forecasts and #NoEstimates
A balanced guide to agile estimation: story points, planning poker, relative versus time estimates, forecasting from throughput and the #NoEstimates debate.
The Agile Coach · Last reviewed October 21, 2026 · 6 min read
Few topics in agile work generate as much frustration as estimation. Stakeholders want to know when something will be ready. Teams know that software work is uncertain and that estimates are easily turned into deadlines. Somewhere between those two positions, teams have to make decisions about what to build and in what order.
Agile approaches do not require any particular estimation technique. The Scrum Guide says the Developers who will do the work are responsible for sizing backlog items, but it does not prescribe story points, hours or any other unit. The Kanban Guide focuses on measuring flow rather than estimating effort.
This guide explains the most common techniques, what each is good for, and the debate over whether teams need estimates at all.
Why Estimate at All?
Estimates are not an end in themselves. They are useful when they support a decision. Common reasons include deciding whether a piece of work is worth its cost, choosing between options, planning how much to take on in a Sprint, and giving stakeholders a sense of when something might arrive.
Keeping the decision in view helps a team choose the lightest technique that will do the job. If the question is "Is this item small enough to finish in a Sprint?", a quick yes-or-no judgment may be enough. If the question is "Can we realistically launch by spring?", a forecast based on historical data is usually more reliable than adding up guesses.
Story Points and Relative Estimation
Story points are a unit for estimating the overall effort needed to complete a backlog item. Mike Cohn describes them as relative: a two-point story should be roughly twice the effort of a one-point story, and the numbers themselves are arbitrary. He suggests a point estimate should reflect the amount of work, its complexity, and its risk and uncertainty.
Ron Jeffries, a signatory of the Agile Manifesto and a longtime Extreme Programming practitioner, has written that he may have invented story points. He explains that XP teams first estimated in time, then in "ideal days," and eventually began calling those units simply points. In a 2019 article, he wrote that he was a little sorry, mainly about how points are misused, for example to compare teams or to track estimates against actuals.
Relative estimation works because people are generally better at comparing two things than at judging one thing in absolute terms. Saying "this feels about twice as big as that one" is often easier and faster than predicting hours. The trade-off is that points are easy to misunderstand outside the team. They are a planning aid for the team, not a measure of productivity.
Relative Versus Time-Based Estimates
Both kinds of estimate have a place, and many teams use both at different levels:
- Time-based estimates, such as hours or days, are intuitive and easy for stakeholders to understand. They work reasonably well for small, familiar tasks, but they tend to be read as promises, and they rarely account for interruptions, waiting and rework.
- Relative estimates, such as story points or T-shirt sizes (small, medium, large), are quick to produce and encourage comparison rather than false precision. Their weakness is that they need translation before anyone outside the team can use them.
- Some teams skip sizing almost entirely and instead split work until items are of similar, small size, then count items. This leads naturally to forecasting from throughput.
Planning Poker
Planning poker is a consensus technique for estimating as a group. James Grenning described it in a 2002 paper written to solve a familiar problem: release planning meetings that stalled while a couple of senior people debated, and everyone else disengaged.
In its basic form, the process looks like this:
- Someone, often the Product Owner, describes a backlog item, and the team asks clarifying questions.
- Each estimator privately chooses a card showing an estimate.
- Everyone reveals their cards at the same time.
- If estimates differ widely, the people with the highest and lowest estimates explain their reasoning.
- The team discusses and votes again, or agrees on a value and moves on.
Decks usually leave growing gaps between the larger numbers, because precision drops as estimates grow. Grenning's original deck had cards for 1, 2, 3, 5, 7 and 10 days plus an infinity card, which signaled that a story was too big and should be split. Many modern decks use a similar sequence of story point values. Grenning's paper also advises not to sweat a lack of consensus on one story: defer it, split it or take the low estimate.
The real value of planning poker is often the conversation. A big gap between estimates usually means people have different understandings of the work, and surfacing that early is worth more than the number.
Forecasting from Throughput
An alternative to adding up estimates is to forecast from what the team has actually delivered. The Scrum Guide notes that in complex environments, only what has already happened may be used for forward-looking decision making. The Kanban Guide defines throughput as the number of work items finished per unit of time.
Imagine a team that has finished between four and nine items per week over the past ten weeks, with 40 similarly sized items remaining. Rather than promising a single date, the team can give a range: at its slowest recent pace, roughly ten weeks; at its fastest, about five. Some teams go further and use Monte Carlo simulation, which samples repeatedly from past weekly throughput to estimate the probability of finishing by different dates.
Throughput forecasting works best when items are reasonably small and similar in size, when the remaining scope is tracked honestly, and when the forecast is updated as new data arrives. It also assumes the future will resemble the recent past, so major changes to the team or the work call for caution.
The #NoEstimates Debate
#NoEstimates is a hashtag and a loose movement that questions how much estimation teams really need. Woody Zuill, often credited with popularizing it, defined it in 2013 as a hashtag for exploring alternatives to estimates of time, effort or cost when making decisions in software development. He also noted that someone else had used the same hashtag in 2010.
Supporters argue that estimation consumes time, that estimates are often misused as commitments, and that delivering small slices of value continuously, combined with forecasting from real data, can answer many of the same questions. Skeptics respond that budgets, contracts, staffing and coordination with other teams frequently do depend on estimates, and that removing them can shift uncertainty onto stakeholders rather than reducing it.
Both sides make reasonable points, and even Zuill has written that if a customer requires an estimate or price, you probably need to provide one. A practical approach is to ask, for each estimate a team produces, what decision it supports and whether a cheaper method could support it just as well.
Key takeaways
- Neither Scrum nor Kanban requires a specific estimation technique; estimate only when it supports a decision.
- Story points are relative effort estimates that are useful within a team and easily misused outside it.
- Planning poker, described by James Grenning in 2002, gets the whole team involved and surfaces hidden assumptions.
- Forecasting from throughput provides ranges based on what the team has actually delivered.
- The #NoEstimates debate raises fair questions on both sides; weigh the cost of each estimate against the decision it informs.
Sources
Spotted something out of date? Let us know.