Agile Planning, Estimation, and the Story Points Illusion

What is Agile Estimation?

Everyone in software development has a scar from a bad estimate. Perhaps it was a death-march project that burned weekends to meet an impossible deadline. Maybe it was a sprint where a “2-point” task blew up into a month-long saga. Agile methodologies promised to make planning saner with an emphasis on adaptive processes and empirical feedback. Yet one practice – story points – has evolved from a clever psychological hack into something that sometimes resembles an organizational illusion.

In this article, we’ll explore the complex reality of agile estimation: why story points were originally invented as a form of psychological safety, how they can be misused in scaled frameworks, and what effective alternatives exist. We’ll examine when estimation adds value and when it becomes organizational theater. By the end, you’ll have a clearer picture of how to approach estimation in a way that genuinely serves your team and stakeholders.

The Central Problem: Estimation Dysfunction

At the heart of software estimation lies a fundamental tension: business needs predictability, while development work contains inherent uncertainty. Traditional approaches to resolving this tension have often led to dysfunction:

• False precision: Detailed estimates in hours or days that create an illusion of certainty
• Accountability without empowerment: Teams held to estimates made with incomplete information
• Estimation as commitment: Confusing estimates (probability) with commitments (promises)
• Political padding: Adding buffers to avoid punishment for “missing” estimates

Story points were designed to address these dysfunctions by creating a layer of abstraction between estimation and time. But have they solved the problem, or just disguised it in new terminology? Let’s explore their origins, benefits, and limitations to find out.

The Psychology of Story Points: Safety in Numbers

Why did story points become so popular in agile? In a word: safety.

Think back to the early days of agile methodologies like Extreme Programming and Scrum. Teams were tired of being held to Gantt charts and “exact” hour estimates. They needed a way to discuss effort that wouldn’t be treated as a carved-in-stone promise. Enter story points – an intentionally abstract unit for estimating work.

By using points (often aligned to Fibonacci numbers like 1, 2, 3, 5, 8, 13…), teams could express relative effort without directly saying “this will take 3 days” – a statement managers might interpret as a binding deadline. Story points were, in essence, a psychological manoeuvre: they obscured the raw data (time) to provide cover for the team.

As agile coach Vasco Duarte bluntly puts it, “story points were an idea that aimed to ‘hide’ information” – specifically, to hide precise duration and create a buffer of ambiguity. This buffer made it easier for developers to give honest estimates without fearing they would become binding commitments.

Key Benefits of the Story Points Approach

The shift from “How long will this take?” to “How complex is this compared to other work we’ve done?” brought several important benefits:

1. Encouraging Valuable Conversations

The process of estimating in points (often via Planning Poker) forces the team to discuss the work in detail. If one developer thinks a story is 2 points and another says 8, that sparks a dialogue: “Why do you think it’s bigger? What risk or complexity do you see?”

These discussions uncover hidden tasks, dependencies, and assumptions, leading to shared understanding. The estimate becomes almost secondary – it’s the conversation that delivers value. Napoleon famously said, “Plans are worthless, but planning is invaluable,” and Planning Poker embodies this principle – it’s a structured mini-planning session disguised as estimation.

2. Defusing Anchoring and Blame

By not using hours, story points help avoid the trap where a developer says “4 days” and is later held accountable for that number despite new information. Story points are intentionally fuzzy.

As Atlassian’s guide quips, an estimate is “not a blood-oath.” It’s a starting point for discussion, not a binding contract. This ambiguity fosters psychological safety: the team can be candid about uncertainty without fear of blame if things change. If the estimate proves incorrect, it’s “just an estimate,” not a missed deadline.

3. Incorporating Complexity and Risk

Story points can encapsulate not just the amount of work, but also its complexity and risk factors. A one-line code change might be scored as 8 points if it’s in a critical, high-risk part of the system, whereas a straightforward but lengthy task might be 5 points.

One Stack Exchange contributor noted that “Story Points reflect the complexity of the problem, and therefore the confidence (or risk) of how accurate the estimate is.” High point values often indicate substantial unknowns – a signal to break down the work or investigate further before proceeding.

When communicating with stakeholders, a high-point item communicates “this contains significant uncertainty” without explicitly stating a time-based uncertainty. It helps manage expectations – a 13-point story subtly says “proceed with caution” to the Product Owner.

4. Decoupling Performance from Estimates

As teams improve, they get more done in the same amount of time. If everything were estimated in absolute days, those estimates would quickly become outdated. Story points avoid this issue.

Because story points don’t map directly to clock time, a team’s velocity (points completed per sprint) naturally increases as they become more efficient, without needing to re-estimate old work. This is a feature, not a bug: it makes improvement visible while avoiding constant re-estimation.

A practitioner gave this example: initially a team delivers ~60 points per sprint; later they handle 70. Why? “Because performance has increased. And you do not need to re-estimate everything after the performance of your team has increased.” If they had estimated in days, they would either stick to the old numbers (missing their productivity improvement) or waste time re-estimating tasks to reflect the new speed.

When Story Points Work Well

Given these benefits, story points can indeed be a useful tool in the right context. They work best when:

1. The team uses them primarily for their own planning
2. The organization treats them as a team-specific capacity planning tool
3. They spark meaningful conversations about complexity and risk
4. They’re used in concert with other empirical measures of progress

Even Ron Jeffries, one of the inventors of Extreme Programming who is sometimes credited with popularizing story points, once saw considerable value in them. However, even Jeffries has expressed reservations about how they’re commonly implemented. He admits “if I did invent story points, I’m probably a little sorry now” and stresses that story points are frequently misused.

His advice is pragmatic: if points aren’t truly adding value for your team, drop them as waste. In other words, story points were never meant to be an agile shibboleth – they were a means to an end, and if they no longer serve that end (of fostering understanding and safety), there’s no shame in abandoning them.

The Foundation for Dysfunction

When used properly, story points can work beautifully as a capacity planning tool for the team’s own use. But they also contain the seeds of their own misuse. The very abstraction that makes them valuable also makes them prone to misinterpretation and organizational dysfunction.

The ambiguity that provides safety for teams can frustrate managers who want certainty. The team-specific nature of points makes them difficult to compare across teams, yet organizations often try to do exactly that. The relative nature of points makes them poor absolute measures, yet many try to use them as precisely that.

These tensions set the stage for the dysfunctions we’ll explore next: how story points can transform from a psychological safety mechanism into organizational theater – what we might call “putting lipstick on a pig.”

The Transformation: How Story Points Become Mechanistic Metrics

Story points were intended to break the mental link between estimates and time. Ironically, many organizations eventually just reattach that link – with extra steps. Nowhere is this more apparent than in large-scale agile frameworks and traditional enterprises adopting Scrum.

In some setups (particularly in big consultancies or implementations of the Scaled Agile Framework (SAFe)), story points effectively become a proxy for “ideal days” or person-days of effort, undermining their original purpose. This is what we call putting lipstick on a pig: renaming the old concept (days of work) with a shiny new term (points) without actually changing how it’s used.

Consider SAFe’s approach to estimation. SAFe advocates for “normalized story points” across teams – meaning, roughly, that one team’s 5-point story should be comparable to another team’s 5-pointer. To achieve this, some SAFe practitioners start with a rule of thumb like “1 point equals 1 ideal person-day of work.”

Essentially, they assign about 8 points per person for a two-week sprint (assuming 80 hours of focus time → ~8 points) to calibrate team velocities. The result? Teams quickly recognize that “1 point is 1 day.” The abstraction is shattered – everyone knows a story point is just a day in disguise. We’re back to the very thing story points were trying to avoid!

Why Standardization Happens

Why do frameworks like SAFe push for normalization? At scale, management wants a common unit for portfolio planning. They want to sum Team A’s estimates with Team B’s estimates and get a single number for a feature or epic.

By forcing all teams onto the same scale, SAFe claims you can roll up estimates for big-picture roadmaps. Indeed, normalizing story point values is considered an accepted practice in SAFe for cross-team coordination. For a feature that spans multiple teams, SAFe would have you sum each team’s points (after scaling them to a “normalized” baseline) to get an overall size.

On paper, this standardization sounds convenient. In practice, it fundamentally misunderstands the nature of story points.

The Problem with Normalization

Agile thought leaders strongly warn against this approach. Scrum co-creator Ken Schwaber says normalization is a bad idea because story points can’t be commoditized across teams. Each team’s points are a local currency – a reflection of that specific team’s composition, experience, and definition of “done.”

Converting them into a universal currency is as problematic as trying to convert “fun” into a KPI. James Coplien put it bluntly: “Managers feel they can compare normalized points but, of course, you can’t. It’s fundamental to relative estimation.”

In other words, a story point only has meaning within the context of the team that estimated it. A 5-point story for a veteran backend team might be a 13-pointer for a new mobile team – and both would be correct assessments in their respective contexts. Forcing them to agree devalues one team’s reality.

Even within a single team, story points were never meant to be precise units. They are buckets, not atomic measurements. As a humorous example, early Extreme Programming teams used units like “Gummy Bears” – yes, the candy – or called them “Nebulous Units of Time (NUTs)” to emphasize their inherent fuzziness.

The specific unit doesn’t matter; what matters is consistency within the team and the conversation the estimation process generates. The moment you start believing that 1 point = X hours universally, you’ve turned gummy bears into clockwork. You’re back to treating estimates as exact, comparable measures, which they fundamentally are not.

So calling a day of work a “story point” doesn’t magically make your planning more agile – it just adds a layer of indirection. Lipstick, meet pig. In fact, it can make things worse by giving a false sense of agility. Management might proudly claim, “We don’t estimate in days anymore; we use story points,” while still expecting fixed scope and dates as if points were hours. This is a classic agile cargo cult: adopting the terminology without the mindset.

The Dysfunctions That Follow

What happens in environments where story points become mechanistic metrics? Typically, a few serious dysfunctions arise:

1. Gaming and Sandbagging

If leadership equates velocity with productivity, teams quickly learn to protect themselves. For instance, if 1 point is implicitly one day, and a team of 5 is expected to do ~50 points in a sprint (10 days each), woe betide them if they only finish 40.

In a healthy agile process, 40 vs 50 points might just mean the stories were larger than anticipated, or there were unforeseen issues – a learning opportunity for next time. But if velocity is treated as a hard target, the team might respond by inflating estimates in the next sprint.

Suddenly the same work that used to be 40 points is estimated at 50, and voila – target met, without anyone working differently. This story point inflation is almost inevitable in an unsafe environment.

A contributor on a Scrum forum observed that when teams are pressured this way, “they immediately understand that 1 point is 1 day,” so they adjust accordingly – essentially converting effort to points mechanistically to avoid trouble. The metric becomes meaningless over time, just as a currency does under hyperinflation.

It’s Goodhart’s Law in action: “When a measure becomes a target, it ceases to be a good measure.”

2. Metric Obsession and False Comparisons

SAFe’s normalized points invite leadership to compare velocities across teams – something agile coaches passionately discourage. If Team A has 100 points per sprint and Team B 50, an uninformed manager might think A is twice as productive.

But such comparisons are fundamentally flawed because the teams likely estimate differently even with attempted normalization. One team might break work into smaller stories or use a different interpretation of points.

The Scrum guide and experienced practitioners like Schwaber insist that the only meaningful measure is working software delivered, not the points themselves. Yet, in practice, companies often rank teams by velocity or scrutinize teams with “lower” velocity – a perverse incentive that further encourages gaming.

3. Return of Dysfunctional Deadline Mindset

When story points = days, managers often just multiply to get timelines. A Project Manager might say: “Team X has a velocity of 25 points, which in our system equals 25 days of work per sprint. Therefore, in the next quarter (6 sprints, ~150 days) they can do 150 points. So let’s commit to 150 points of work.”

This is waterfall thinking resurrected. It assumes perfect predictability and zero change in velocity, and often ignores that story point velocity is an empirical measure, not a promise. It also slides back into the idea that if velocity falls short, the team must have “underperformed” – rather than treating velocity as a diagnostic tool.

The Core Issue: Misunderstood Purpose

All of this is not to specifically criticize SAFe (though it often deserves scrutiny) but to illustrate a broader point: Story points are easily corrupted when their purpose is misunderstood.

They were meant to be a tool for a team to gauge its own capacity and to communicate with stakeholders in fuzzy terms. They lose meaning when coerced into a universal unit or a strict performance metric.

As one agile expert summarized, “story points do have a place, but what is wrong in our industry today is that as a unit, they are abused, and as a phrase, often overloaded. They are a capacity planning tool and not a measure of productivity.”

When you treat them as a productivity measure or, worse, as just repackaged hours, you miss the whole point (pun intended).

Lipstick on pigs helps no one. If your organization is basically doing time estimates but calling them story points, be honest about it. You’d likely be better off either truly embracing relative estimation (and keeping management’s hands off team velocity), or just using hours openly rather than maintaining a facade.

In the end, it’s about having realistic plans and healthy communication – which can be achieved in multiple ways. That brings us to our next topic: reviewing the palette of estimation (and non-estimation) approaches and when each is most appropriate.

Estimation Techniques: Picking the Right Approach for Your Context

Agile teams have experimented with numerous ways to estimate (or avoid estimating) over the years. Let’s systematically review the main approaches, their strengths and limitations, and the contexts where each makes the most sense.

Remember that estimation is not one-size-fits-all – what works for a small co-located startup may fail in a large distributed enterprise, and vice versa. The key is understanding why you’re estimating in the first place and what you hope to achieve through the process.

Story Points and Planning Poker

We’ve already covered story points in depth. To recap their essence: they are a relative size measure, usually assigned via Planning Poker – a consensus-based estimation technique where team members simultaneously reveal point cards to avoid anchoring bias.

If everyone shows the same number, you move on. If not, the high and low estimators explain their reasoning, the team discusses, and then plays another round until consensus (or at least convergence) is reached.

Most teams use the Fibonacci sequence (1, 2, 3, 5, 8, 13, 20, …), which intentionally creates larger gaps at higher numbers to reflect greater uncertainty. Some teams use t-shirt sizes or other scales, but the idea remains the same: bucket items into relative size categories.

(Fun historical note: Early XP teams sometimes used actual candy like M&Ms or Gummy Bears as tokens for estimates – one candy = one “point” – to remind everyone it’s just a playful estimate, not science.)

When to use story points

Story points work best in these contexts:

1. Long-lived teams doing ongoing iterative development where measuring velocity can help with sprint planning and release forecasting. After a few sprints, the team sees a pattern (“we usually finish about 30 points each sprint”), which helps them avoid overcommitting in future sprints and gives Product Owners a rough gauge of how many stories can fit in a release.
2. When you want to encourage team discussion about the work – e.g., during backlog refinement or sprint planning, as a way to flesh out acceptance criteria and dependencies. If your team finds value in those conversations and the relative sizing, story points can be a useful team-internal metric.
3. With new teams needing to normalize different estimation styles – e.g., one developer might think in terms of effort, another in complexity; by debating points, they learn from each other and calibrate a common understanding.

Pitfalls of story points

Story points have several common failure modes:

1. Misuse as rigid performance metrics, as we saw in the previous section.
2. Time-consuming estimation sessions that feel tedious when overdone. Estimating every single backlog item in points can feel wasteful if those estimates aren’t used for meaningful planning.
3. Analysis paralysis over whether something is 8 or 13 points, which is usually not worth the time spent. Mike Cohn suggests keeping estimation lightweight – e.g., timeboxing Planning Poker sessions or only estimating enough for near-term planning.
4. The granularity illusion: Points give a veneer of quantification that can seduce people into false precision. For instance, summing up story points to say “this project is 128 points total” can lead to a false sense of certainty (“128 points = X sprints, we’ll be done by June”). Always remember that points are relative guesses, not precise measurements.

In summary, story points are effective when you need a team calibration tool and a way to roughly measure capacity over time, provided you have the right organizational culture to use them properly. Many Scrum teams do fine with them – as long as they’re kept in perspective as team-specific, coarse-grained indicators. When in doubt, heed Ron Jeffries: if they aren’t adding value, don’t hesitate to drop them.

Ideal Days (Ideal Engineering Hours)

Before story points, many agile teams (and some still today) estimated in Ideal Days or Ideal Hours. An “ideal day” means “one developer’s full day of work if they had no interruptions and everything went smoothly.”

It’s a unit closer to time, but with the important qualification that we rarely get truly “ideal” days in reality. Mike Cohn’s book Agile Estimating and Planning discusses ideal days at length.

The approach involves estimating how many ideal days a story would take, then later adjusting for reality by applying a focus factor. For example, if developers actually get about 6 hours of productive time per day due to meetings and overhead, you adjust accordingly.

Some teams prefer ideal days because they’re more intuitive – even a non-developer can grasp that “Feature X is about 5 ideal days of work” more readily than “Feature X is 8 points.”

When ideal days make sense

Ideal days can be appropriate in these contexts:

1. Environments where story points cause more confusion than clarity, particularly for stakeholders who think in calendar time.
2. Organizations where management insists on time-based planning. For example, I coached a team at a company where every other department worked with detailed Gantt charts. Presenting purely story-point based timelines to the PMO was causing friction (“what the heck is a point?”). We switched to estimating in ideal days (with an agreed conversion like ideal days * 1.5 = actual days) to speak a language the PMO understood. It wasn’t pure agile, but it avoided miscommunication.
3. Very small teams or solo developers, where the overhead of story points might not be worth it – ideal days could be sufficient because the “team calibration” aspect is less important when one person is doing most of the work.

Drawbacks of ideal days

Ideal days come with significant limitations:

1. They reinforce time-based thinking. Saying “2 ideal days” too easily translates in a manager’s mind to “you’ll be done by Wednesday” – even though the whole point of “ideal” is that real life may differ significantly.
2. Estimated ideal days can become outdated if a team’s productivity improves. Unlike story points which account for improvement through velocity changes, ideal days may need re-estimation or focus factor adjustments over time.
3. They encourage task-level focus (“how long will I take to do this”) rather than a holistic story discussion. Teams new to agile sometimes slip back into dividing stories into tasks and estimating each in hours – which can be useful for sprint planning, but if done too much, it feels like waterfall in disguise.

Ideal days might be appropriate in certain contexts – particularly when translating agile to traditional stakeholders – but they carry a higher risk of misinterpretation and misuse. If you do use them, treat them carefully: always append “ideal” and frequently remind everyone that reality may differ significantly.

T-Shirt Sizes and Bucket Estimation

Another lightweight approach is using T-Shirt Sizes: XS, S, M, L, XL (and maybe XXL) to classify stories or epics. This technique often comes into play during early product discovery or roadmap planning, when you don’t have enough detail for fine-grained estimates.

For example, a Product Manager might ask an agile team, “How big is Feature A relative to Feature B?” and the team could respond “Feature A is Large, Feature B is Small.” This gives a coarse sense of scope without spending too much time on detailed estimation.

The categories can correspond to rough ranges of effort (e.g., maybe S ~ 1-2 sprints of work, M ~ 2-4 sprints, etc., depending on your context). It’s deliberately imprecise.

When to use T-shirt sizing

T-shirt sizing works well in these scenarios:

1. High-level estimation and portfolio planning when precision isn’t possible or necessary. If you’re prioritizing a backlog of 50 new ideas, you might just bucket them into sizes to help sequence work: you might choose a mix of small and medium items for the next quarter rather than only extra-large projects.
2. Communication with non-technical stakeholders. T-shirt sizes are metaphorical and easy to grasp (everyone knows an XL is bigger than an M). This can be useful when presenting to executives or clients who just want a ballpark, without diving into points or hours.
3. High-level comparison across teams in a loose way without pretending to be precise. One team’s “Large” might not be exactly the same effort as another team’s “Large”, but as long as leadership treats it as a broad bucket, that’s usually fine. In fact, SAFe at the Program level sometimes uses T-shirt sizes for epics before decomposing into points at the team level.

Limitations of T-shirt sizing

T-shirt sizes have important limitations:

1. Not suitable for detailed planning. You can’t really sum up “S + L + M” and get a meaningful total the way you might add story points.
2. Inconsistent mental models of what “Large” means across teams, which could cause confusion if not aligned.

However, the good news is, because T-shirt sizing is so clearly not scientific, stakeholders might be less inclined to misuse it. No one schedules a project to the day because it was tagged “XL” – they recognize it’s just a vague indicator. In a way, this approach embraces uncertainty more openly than numeric approaches.

“No Estimates” (#NoEstimates)

On the far end of the spectrum from detailed estimation is the provocatively named NoEstimates movement. Despite the label, #NoEstimates doesn’t imply no planning or flying blind. It’s more about questioning the necessity and value of estimating every piece of work, especially when you can use historical data and flow metrics to forecast outcomes instead.

The origins of NoEstimates trace back to conversations on Twitter around 2012, notably between Woody Zuill, Vasco Duarte, and Neil Killick. They each had slightly different angles:

• Woody Zuill argued that if you focus on continuously delivering small, valuable increments, you might not need to estimate them – just do the most important thing next, and measure progress by delivered value.
• Vasco Duarte and others advocated using throughput (e.g., stories completed per sprint or per week) to project timelines rather than estimating story by story.

The common theme was a frustration with the waste and false certainty that often accompany traditional estimation.

The #NoEstimates approach

One way to think of NoEstimates is as a natural extension of agile’s empirical approach: if you have a stable, consistent team, just measure what they actually deliver over time and use that to forecast the future, instead of guessing upfront. A typical process might look like:

1. Break work into small, roughly similar chunks. This often means slicing stories thin, aiming for pieces that are small enough that variation isn’t huge (e.g., 1-3 days each).
2. Track throughput – Count how many stories (or story points, or whatever unit) the team completes in each sprint or week.
3. Use that data to forecast. For instance, if a team reliably finishes about 5 stories per week (sometimes 4, sometimes 6), and the backlog has 50 stories, you can project roughly 10 weeks of work. More rigorously, you could run a Monte Carlo simulation on the throughput data to get a probabilistic range (e.g., 85% confidence of finishing in 11 weeks).
4. Continuously re-evaluate. Because you’re using real data, you can update the forecast every iteration as new throughput data comes in or scope changes.

This approach shifts the conversation from “How many points is this story?” to “How many stories can we typically deliver in a month, and thus how long for X stories?”. It treats each work item more uniformly, avoiding the need to assign a specific estimate to each.

When #NoEstimates works well

#NoEstimates can be highly effective in these contexts:

1. Stable teams working on similar-sized work. In this scenario, historical throughput can be far more reliable and efficient than story-by-story estimation. Stability is key – W. Edwards Deming famously said you need a system in statistical control (with only common cause variation) to predict reliably.In software terms, that means consistent team composition, comparable work types, and minimal external disruption. Under those conditions, throughput per sprint or cycle time per item can converge to a relatively stable range.
2. When estimation overhead outweighs its value. If your team finds that Planning Poker sessions consume hours that could be spent building, and yet the estimates are often inaccurate anyway, you might experiment with skipping estimation and focusing on limiting work in process and delivering continuously.Some teams report that emphasizing small batch flow and frequent delivery gave stakeholders enough confidence that formal estimates weren’t missed.

The benefits of #NoEstimates include:

• Time savings: No lengthy estimation meetings
• Avoiding false precision: Acknowledging the inherent uncertainty in predictions
• Forcing focus on small batches: Encouraging work to be sliced into manageable pieces
• Improving trust: Instead of arguing over estimates, the team demonstrates progress every sprint with working software

When #NoEstimates struggles

Not every context is suitable for this approach:

1. Unstable teams: If people are constantly joining and leaving the team, or you’re frequently reorganizing, then past throughput won’t be predictive.
2. Highly variable work: If the nature of work fluctuates dramatically (one week fixing 10 small bugs, the next week tackling a huge architectural refactoring), throughput will be inconsistent and less useful for forecasting.As one agile practitioner noted, #NoEstimates works best when you don’t need estimates to begin with – i.e., when you have consistent flow. If you have erratic flow, you might still need to estimate large items to understand their impact.
3. Scale or fixed-scope projects: Management sometimes requires upfront projections of how long a project will take or how much it will cost. #NoEstimates advocates would suggest you can still forecast by delivering an MVP and measuring velocity, but many organizations are uncomfortable with “we’ll see as we go.”In such cases, you might combine approaches: perhaps estimate at a high level (T-shirt sizes or points for epics) to satisfy planning needs, then use #NoEstimates principles for day-to-day execution.

Critics of #NoEstimates sometimes argue it’s essentially saying “we’ll figure it out when we get there.” Proponents reply that using throughput is actually a better way to hit deadlines than guesswork based on limited information.

Both sides agree you can’t ignore stakeholder needs; NoEstimates is about finding alternative ways to answer the “when will it be done?” question based on empirical data rather than speculative estimation.

Other Estimation Techniques

For completeness, several other estimation approaches exist, though they’re less common in typical agile environments:

• Function Point Analysis: Sizing based on functional specifications, more common in traditional IT environments
• COSMIC and other formal measures: Primarily used in regulated environments with strict measurement requirements
• Affinity Estimation: A technique for quickly grouping stories by similar size instead of using Planning Poker
• Team Estimation Game: A collaborative workshop format for rapid estimation

However, our focus here is on the major approaches in mainstream agile practice, which largely come down to the ones detailed above.

Comparison: When to Estimate vs. When to #NoEstimate

Let’s create a more systematic comparison of when to use different estimation approaches:

Let’s examine some specific scenarios in more detail:

Stable Team, Continuous Flow

With a stable, long-lived team working on a continuous flow of similar work, you might not need detailed estimates at all. If the team has predictable throughput, consider using that for planning (#NoEstimates style).

Example: A team has consistently completed between 25-30 story points (or 5-7 user stories) every iteration for the last 10 iterations. They work from a prioritized backlog that can be re-scoped based on feedback.

In this case, plan in terms of “features per iteration” and feed the team prioritized work; they’ll likely maintain the pace. Estimates for individual stories might not add much value – the velocity data tells the story.

Instead of estimating, the team can focus on refining backlog items to be small and clear, which will help maintain steady throughput. One effective interpretation of #NoEstimates is simply “counting the number of valuable backlog items delivered to Done per Sprint” and using that for forecasting. If throughput is consistent and quality is good, this may be all you need.

New Team or Project with Unknowns

When starting a new team or project, you typically lack historical data. In this scenario, estimation becomes more valuable, not primarily for predicting delivery dates, but for uncovering complexity and assumptions.

The act of estimation often surfaces critical questions (“Have we accounted for deployment?” “What if the API isn’t ready?”). In this context, doing at least high-level estimates (like T-shirt sizing epics or rough points on stories) helps map out the work and identify risks.

It also helps establish a baseline velocity after the first few sprints, which can inform future planning. You might start with more rigorous estimation practices and then ease off as the team stabilizes and gains historical data.

Importantly, initial estimates should be communicated with wide uncertainty ranges (“We think 3-5 sprints, but that’s a rough guess”) to set realistic expectations. The process of estimation in this context is as much about risk identification as it is about duration prediction.

Unstable Team or Variable Scope

If your team composition changes frequently (e.g., contractors coming and going, or a matrix organization where people split time across projects), the benefits of story points or careful estimates diminish significantly. Velocity will fluctuate too much to be reliably predictive.

In these environments, some leaders insist on even more estimation (to try to control the chaos), but that’s like trying to measure fog with a ruler. A better approach is to address the root problem (stabilize teams or break work into more independent slices) rather than investing heavily in estimation.

If instability is unavoidable, you might use very high-level estimates for short-term planning, but accept that accuracy will be limited. For example, if a new team forms around a project with a 3-month deadline, you might do a rough estimate of features to validate feasibility, but then track progress aggressively with frequent check-ins and adjustments.

Low-Trust or High-Pressure Environment

This scenario deserves special attention. If the fundamental reason you’re debating estimation approaches is that management doesn’t trust the team (or vice versa), the solution isn’t in the estimation technique – it’s in the relationship dynamics.

In a culture of fear, teams might prefer story points as a shield (“the points say it’s done when it’s done”), while management might push for hours because they want control. Both sides might play games: the team inflates points to build safety, managers secretly convert points back to hours to enforce deadlines.

In such an environment, no technique will produce “accurate” estimates because the process is adversarial. The first step should be working on transparency and trust. Try doing estimates together with product managers and developers in the same room, openly discussing assumptions and risks.

The goal is to make it safe to be honest. If a developer says “This might be 5 days of work but could blow up because of X dependency,” and management responds constructively, you’ve made progress.

If everyone is still trying to outmaneuver each other, consider bringing in an agile coach to reset expectations. Sometimes switching to #NoEstimates (delivering in small increments and showcasing progress often) can rebuild trust because it emphasizes results over predictions.

Regulatory or Contractually Fixed Projects

Some projects (think FDA-regulated medical software or a fixed-price client contract) require upfront estimates for compliance or contractual purposes. In these cases, story points can be difficult to use externally (the client might not accept “it’s 100 points” as a quote).

One approach is to estimate in points internally, then use historical data (if available) to translate that to a range of time or cost for external communication. If your team’s velocity has been roughly 20 points = 2 weeks, and you estimated 100 points of work, you might quote ~10 weeks with a confidence interval.

However, this feels scientific but is still a forecast, not a guarantee. Many agile contracts use a “Not to exceed” approach or phase funding: complete a short phase, measure actual velocity, then replan.

If you must fix scope/time/cost simultaneously (the infamous triple constraint), be sure to include contingency buffers and clear risk language in your agreements. While #NoEstimates isn’t typically applicable for initial contracting, you might still execute internally in a flow-based way after contracts are signed.

The Foundation: Trust and Transparency

Across all these scenarios, one theme remains consistent: estimation works best in an environment of trust and transparency. Whether you use points, days, or #NoEstimates, the quality of your forecasts depends heavily on the psychological safety of your team.

In the next section, we’ll explore this human dimension of estimation: how fear and distrust can corrupt any estimation system, and what to do about it.

The Elephant in the Room: Trust, Fear, and Honest Conversations

We can’t meaningfully discuss estimation without addressing the human dynamics that shape it. All the techniques we’ve explored so far—story points, ideal days, #NoEstimates—are merely tools. Like any tool, their effectiveness depends greatly on how they’re used and the environment in which they operate.

Let’s examine two contrasting scenarios to illustrate how organizational culture affects estimation:

Scenario 1: The High-Trust Environment

In this environment, the team and leadership trust each other implicitly. When the team says an item is 8 points (or 5 days, or Large—pick your unit), it’s accepted as their best professional judgment, not as lazy padding or a commitment to be enforced.

If things change—a story turns out more complex than anticipated, a technical roadblock appears—both sides discuss the new reality openly. Management’s primary concern is understanding the challenges and adjusting plans accordingly, not assigning blame. The team’s focus is delivering value and flagging risks early, not protecting themselves from unreasonable expectations.

In this context, the specific estimation technique matters far less than it might elsewhere. Estimates become what they should be: collaborative tools for planning, not weapons in an organizational power struggle.

Scenario 2: The Low-Trust Environment

Contrast that with a low-trust environment. Management suspects the team might be padding estimates or sandbagging. The team suspects management will punish them for any slip or try to cram more work in if they show any slack.

In this atmosphere, estimation turns into a psychological chess match. It becomes a mind-game of who blinks first. Teams might deliberately over-estimate (sandbag) every item to build a safety buffer. Management, aware of this, might secretly scale down every estimate (“the team said 8, but I bet it’s really 5”) or push for “stretch goals” beyond the estimate. It’s a vicious cycle of distrust.

Story points were supposed to help by introducing ambiguity—but humans are adaptable. If a team doesn’t feel safe, they might assign 8 points to something they truly think is 5 points of work, essentially baking in a hidden 3-point buffer.

I’ve seen teams where the unwritten rule was “when in doubt, round up to the next Fibonacci number and then some.” If questioned why a seemingly simple task is 5 points, they’d cite vague risks, but the real reason was a history of being burned by tight deadlines and wanting protection. This is sandbagging in story point clothing.

How Gaming Corrupts Estimation

One agile practitioner shared a revealing anecdote about a developer who boasted about completing “13 story points in a single day”—a feat that should be impossible if the team’s points were calibrated meaningfully. Clearly, this points system was being gamed (perhaps through inflated estimates or cherry-picking high-point, low-effort tasks).

When velocity becomes a performance yardstick instead of a planning tool, teams will inevitably find ways to optimize for the metric rather than for value delivery. They might:

• Inflate estimates to make velocity targets easier to hit
• Split stories in ways that maximize points rather than value
• Cut corners on quality (creating invisible technical debt) to hit sprint goals
• Avoid tackling complex, risky work that might endanger velocity targets

Management isn’t immune from gaming behavior either. Common management tactics in low-trust environments include:

• Imposing arbitrary velocity increases (“Your team’s velocity has been ~30 points; we need you to deliver 40 points next sprint”)
• Secretly converting points back to hours for tracking
• Shaving estimates (“you said 8 hours, but I think it can be done in 6”)
• Using velocity as a primary performance metric in reviews

The fundamental issue isn’t which estimation technique you use—it’s the lack of psychological safety. No process or tool can compensate for a culture where people aren’t allowed to be honest about uncertainty or complexity.

In fact, using story points as a psychological safety crutch can backfire if it allows the underlying distrust to fester unaddressed. It’s like painting over mold—it looks better temporarily, but the wall is still rotting inside.

Building a Culture of Trust Around Estimation

So what’s the solution? Radical honesty and culture change. Leaders should encourage teams to provide realistic estimates (or forecasts) without fear. Teams should be upfront about what they don’t know. Both sides need to treat estimation as a collaboration, not a negotiation with winners and losers.

Practical Strategies for Building Trust

1. Make it safe to give bad news early

If a team realizes mid-sprint that they will miss a goal, that information should surface immediately without repercussion. Leadership should reward transparency (“Thanks for telling us early; let’s adapt”) instead of shooting the messenger.

This encourages teams to avoid padding everything “just in case,” because they know they can raise issues as soon as they identify them. Early warning of problems is far more valuable than the illusion of perfect execution.

2. Separate estimation from evaluation

Don’t use estimates or velocity as performance evaluation metrics. Use them for planning, yes, but when you tie performance reviews or bonuses to velocity, you’ve virtually guaranteed the numbers will be manipulated (consciously or not).

As a wise saying goes, “Metrics are for insight, not judgment.” Use other methods to evaluate performance (code quality, value delivered, stakeholder feedback)—not raw point counts. Remember that “metrics do not equal targets”—if you turn them into targets, you sacrifice the value of the metric.

3. Educate stakeholders on uncertainty

Often, distrust isn’t personal—it’s systemic, coming from upper management or clients who expect certainty where none exists. Educating them on the realities of software complexity can help set more realistic expectations.

Analogies often work well: “We’re doing something innovative here—asking exactly when it will be done is like asking a scientist exactly when they’ll have a breakthrough. We can give a range and we’ll keep you updated, but we can’t guarantee a date with 100% certainty.”

Also emphasize that change is inevitable—new requirements, bugs, etc.—and a good agile process adjusts rather than sticking to an outdated plan.

4. Use data to build trust

Over time, as the team delivers and data accumulates (velocity trend, cycle times, etc.), use it to have frank conversations:

“Look, our velocity fluctuated when we had those two production issues, otherwise it’s stable. When we commit to 40 points we often only get 35 done—let’s adapt to commit 35 going forward to be realistic.”

Or “Our cycle time for stories is averaging 4 days with a standard deviation of 1—so roughly 85% of the time, a story is done within 5 days. That’s our current system capability.”

Presenting evidence takes the emotion out of the discussion and shows that the team isn’t sandbagging—the system is what it is. Then the conversation can shift to improving the system (addressing root causes of delays or blockers) rather than finger-pointing about estimates.

A Case Study in Trust Building

Let me share a brief case study from a team I coached. When I first joined, estimates were a battleground. The team routinely padded story points, and management routinely discounted them, assuming 30% padding. Neither side trusted the other.

We took three key steps:

1. Introduced retrospectives specifically about estimation accuracy, where we tracked estimated vs. actual effort without blame. This created awareness of patterns.
2. Established a “risk register” where the team could explicitly call out uncertainties separate from the estimate. Instead of padding an estimate from 5 to 13 points because of a risky dependency, they’d estimate it at 5 and add a clear risk note: “This assumes the API team delivers on time; if not, we’ll need to reassess.”
3. Invited key stakeholders to planning poker sessions as observers. This helped them understand the thought process behind estimates and see that the team wasn’t arbitrarily assigning numbers.

Within three months, we saw a marked change. The team began giving more accurate, unpadded estimates because they knew risks would be tracked separately. Management stopped second-guessing estimates because they understood the reasoning. Most importantly, when something did go wrong, the conversation shifted from “why was your estimate wrong?” to “what can we learn from this?”

Beyond Numbers: Honest Conversations About Complexity and Risk

The most valuable aspect of estimation isn’t the numbers themselves—it’s the conversations they spark about complexity, dependencies, and risks. When these conversations happen in a psychologically safe environment, they naturally lead to better planning and execution.

The Value of Uncertainty Ranges

One practice that helps foster honest conversations is using uncertainty ranges rather than single-point estimates. Instead of saying “This feature will take 5 points,” a team might say “We’re 90% confident this will take between 3 and 8 points.”

This approach has several benefits:

• It acknowledges the inherent uncertainty in software development
• It prevents artificial precision that can mislead planning
• It naturally leads to discussions about what factors could push the work toward the upper or lower end of the range
• It sets more realistic expectations with stakeholders

Some teams use Monte Carlo simulations based on historical data to generate these ranges for larger initiatives. For example, “Based on our throughput over the last 10 sprints, we have an 85% confidence of delivering these 15 stories between sprints 23 and 26.”

This probabilistic forecasting approach aligns expectations with reality and, ironically, often builds more credibility than single-point estimates because it shows you understand there are unknowns.

A Focus on Small Batches

Another practice that reduces the estimation burden while promoting honest conversations is a relentless focus on small batches of work. When items are kept small (ideally a few days or less), detailed estimation becomes less critical—the variability is naturally constrained.

This approach is core to both Kanban and #NoEstimates thinking. By shifting the conversation from “How long will this large feature take?” to “How can we deliver thin vertical slices of value quickly?”, you not only reduce estimation error but also create more frequent opportunities for feedback and course correction.

A team I worked with in the financial sector replaced their complex estimation process with a simple rule: “No story should take more than 3 days; if it does, split it until it doesn’t.” They then used flow metrics (average completion rate) rather than upfront estimates to forecast. Not only did this save hours of estimation meetings, but it also resulted in more predictable delivery and better stakeholder satisfaction.

Align Incentives with Outcomes, Not Outputs

A final key aspect of building trust around estimation is aligning incentives properly. If leadership primarily rewards hitting velocity numbers or meeting arbitrary deadlines, teams will optimize for those metrics—even at the expense of quality, innovation, or long-term sustainability.

Instead, focus incentives on business outcomes (features that earn or save money, user satisfaction, etc.). When teams know that delivering value is the real goal, they’re less likely to game estimation; in fact, they’ll push to deliver more value faster.

Conversely, if leadership only ever asks “Did you hit the velocity number? Did you meet the date?”, people will optimize for that even at the cost of the product (hello technical debt and quick fixes). Leaders need to be careful what they incentivize.

As the Vietnam War “body count” story illustrates, choosing the wrong metric (kills, story points, etc.) and rewarding it can lead to horrific outcomes. The metrics you choose to emphasize will shape behavior—for better or worse.

A Framework for Healthy Estimation

To pull these threads together, here’s a simple framework for creating a healthy estimation culture:

1. Start with why
   • Clarify the purpose of estimation (planning capacity, communicating with stakeholders, etc.)
   • Be honest about organizational constraints (regulatory requirements, contract terms, etc.)
   • Match the estimation technique to the actual need
2. Create psychological safety
   • Separate estimation from evaluation
   • Make it safe to revise estimates as new information emerges
   • Reward transparency about risks and blockers
3. Embrace uncertainty explicitly
   • Use ranges and confidence levels rather than single-point estimates
   • Track estimate accuracy to learn, not to blame
   • Educate stakeholders on the nature of software complexity
4. Focus on value flow, not estimates
   • Keep work items small to reduce variability
   • Measure throughput and cycle time as planning tools
   • Celebrate delivered value, not velocity
5. Continuously improve
   • Regularly reflect on estimation accuracy and process
   • Adjust your approach based on team feedback
   • Be willing to drop practices that don’t add value

In a positive, trust-filled environment, you might find you don’t need heavy estimation processes at all—teams can give rough forecasts or even use #NoEstimates approaches and still deliver reliably because everyone’s working toward the same goal and communicating openly.

Conversely, in a toxic environment, even the best estimation techniques will be corrupted. Remember that agile methodologies always prioritize individuals and interactions over processes and tools. Estimation is just a tool; if the individuals and interactions are dysfunctional, the tool won’t fix the underlying problems.

Beyond the Illusion: Using the Right Tool for the Right Job

With this understanding of the critical role trust plays in estimation, let’s move toward our conclusion. How do we take all this knowledge about story points, alternative techniques, and the importance of psychological safety, and apply it in practical terms?

The answer isn’t a one-size-fits-all technique, but rather a mindset that selects and adapts the right approach for each context, while always prioritizing honest communication over the illusion of precision.

Conclusion: Beyond the Illusion – Practical Steps Forward

We’ve covered a lot of ground in this exploration of agile estimation. We’ve seen how story points originated as a psychological safety mechanism, how they can be corrupted into glorified time estimates, and how trust fundamentally shapes the effectiveness of any estimation approach. Now let’s bring it all together with practical guidance for moving forward.

Reclaiming the Purpose of Estimation

First, let’s reclaim the true purpose of estimation. It was never about pinpointing an exact date of completion with perfect accuracy. It’s about understanding the relative effort and risk of work items so we can make informed decisions about:

• What to prioritize
• What might not be worth doing at all
• How to sequence work for maximum learning and value delivery
• How to communicate realistic expectations to stakeholders

In agile, estimates (if used) are part of a feedback loop—we estimate, observe actual results, then adjust our approach. They are not promises written in stone; they are inputs to planning that will evolve as we learn. When everyone in the organization internalizes this mindset, the pressure around estimation diminishes significantly.

A Decision Framework for Choosing Your Approach

Instead of prescribing a single “best” method, here’s a practical decision framework to help select the right estimation approach for your specific context:

1. Start by assessing your environment:
   • How stable is your team? (Consistent team → more empirical approaches)
   • How much historical data do you have? (More data → more forecasting, less upfront estimation)
   • What’s the level of trust? (Low trust → focus on building trust before changing estimation)
   • What external constraints exist? (Contracts, regulations → may require more formal estimation)
2. Match the technique to the specific question:
   • For “Can we deliver these 5 features by Q4?” → Quick estimation session on those features with ranges
   • For “How many stories can we finish this sprint?” → Look at velocity or throughput from past sprints
   • For “What should our yearly roadmap include?” → Use T-shirt sizes and historical throughput
   • For “How much will this fixed-bid project cost?” → More detailed estimation with risk buffers
3. Be agile about your agile practices:
   • If your team is new and benefits from estimation discussions → Use Planning Poker
   • If your team is mature and finds estimation meetings wasteful → Try #NoEstimates
   • If management needs numbers → Give them forecasts, but focus internally on continuous delivery
4. Choose the level of precision appropriate to the decision:
   • Long-term planning (quarters/years) → Coarse-grained estimates (T-shirt sizes)
   • Medium-term planning (months) → Story points or throughput forecasts
   • Short-term planning (weeks) → Finer-grained techniques, possibly task breakdowns

Case Study: Practical Adaptation

To illustrate this adaptive approach, let me share a case study from a product organization I worked with:

Starting point: A company with six development teams, each using story points differently, with significant estimation overhead (2-3 hours per week in estimation meetings) and low predictability.

The approach we took:

1. Short-term planning (Sprint level):
   • Kept story points but simplified to just three values (1, 2, 3) representing small, medium, large
   • Limited estimation meetings to 30 minutes
   • Focused on breaking down stories to ensure most were “small”
2. Medium-term planning (Release level):
   • Stopped summing story points for release planning
   • Instead, tracked throughput (stories completed per sprint) and story breakdown rates
   • Used Monte Carlo forecasting to give date ranges with confidence levels
3. Long-term planning (Roadmap level):
   • Used T-shirt sizing for epics
   • Provided rough delivery windows (quarters) rather than specific dates
   • Established regular checkpoints to revise forecasts based on actual delivery data
4. Trust building:
   • Created visualization showing historical accuracy of estimates vs. actuals
   • Conducted “risk reviews” separate from estimation to explicitly discuss uncertainties
   • Educated stakeholders on probabilistic forecasting

The results:

• Reduced estimation meetings by 75% (from 2-3 hours to 30 minutes weekly)
• Improved predictability (from 60% to 85% of commitments met)
• Increased stakeholder satisfaction with planning process
• Teams reported higher engagement and less “estimation fatigue”

The key insight wasn’t finding the “one true estimation technique” but rather using the right level of detail for each planning horizon while continuously building trust through transparency.

Transparency with Uncertainty

One strategy I frequently recommend is transparency about uncertainty. Instead of hiding behind story points or detailed Gantt charts to avoid tough conversations, face uncertainty head-on.

For example, in sprint reviews or stakeholder meetings, openly discuss what the team has learned and how that affects estimates or forecasts:

“We initially estimated 8 points for this feature, but we discovered an integration issue that will add about 3 more points of work—so we’ve adjusted our timeline. This affects the delivery date for feature X, which now looks likely to slip to the next sprint.”

This kind of openness can be intimidating in a low-trust environment, but it’s also the antidote to distrust. When stakeholders see that the team isn’t arbitrarily missing estimates but rather dealing with reality as it unfolds, they develop more confidence in the team’s future forecasts.

This approach of “confident uncertainty” often builds more credibility than false precision. It demonstrates both expertise (you understand the system and its challenges) and honesty (you’re not hiding information to look good).

Measuring What Matters

Agile expert Ron Jeffries encourages courage and candor over pleasing fantasies. He suggests that rather than measuring progress by story points, teams could simply count “stories completed” or measure delivered features, and use that empirical data. The specific technique matters less than real progress.

Vasco Duarte similarly reminds us that story points often yield less information than other metrics readily available. Teams have access to cycle time data, lead times, throughput, and actual hours logged. If you want to forecast or diagnose issues, these direct measurements can be more useful than story points, which are an intermediate abstraction.

This call to be more empirical and evidence-driven is at the heart of mature agile practice. Make use of the rich data your development process generates—velocity trends, yes, but also defect rates, customer feedback, cycle times—when making decisions. Don’t obsess over the estimates given in a refinement meeting at the expense of actual delivery data.

Regular Review of Estimation Practices

In practical terms, here’s a recommendation: periodically review your estimation process. Have a retrospective specifically about “how we do planning and estimation.” Ask the team and stakeholders:

• Are our estimates serving us?
• Are they used constructively?
• Do they help us foresee and mitigate risks?
• Or are they causing friction and waste?

You might discover that you’re spending 4 hours per week estimating, but no one actually uses those estimates after the meeting—potentially a significant opportunity to reclaim time for value-adding work.

Or perhaps stakeholders are making unreasonable demands based on estimates—that’s a chance to adjust how you communicate those estimates and to educate on the nature of software development uncertainty.

Continuous improvement applies to meta-processes like estimation too. Don’t keep doing something just because “that’s how we’ve always done it.”

Addressing the “Illusion” Head-On

Finally, let’s address the “illusion” aspect directly. The story points illusion refers to the false comfort they can provide—the notion that we’ve somehow tamed uncertainty by assigning a number to it.

An illusion can be useful (it might temporarily calm anxieties), but it becomes dangerous when we start believing in it. Always remember that estimates—in points, days, or jellybeans—are fundamentally uncertain.

By maintaining this humility, you’ll naturally gravitate toward honest conversations about complexity, risk, and delivery expectations. For example, instead of just saying “This will be 5 points, let’s do it,” a team might say:

“We rated this 5 points, assuming the API is already available. If not, it could be 8 or more. Let’s do a quick spike to confirm the API status, or at least flag the risk to the Product Owner.”

That’s an honest conversation stemming from an estimate. By contrast, a dysfunctional process might sound like “5 points? Great, moving on” when everyone secretly knows the API might not be ready—because they don’t feel safe raising concerns. Strive for the former approach: honest, direct, and focused on surfacing risks early.

A Call to Action: Keeping It Real

Agile planning doesn’t need to be an anxiety-inducing circus or a blame game. It should be a collaborative effort to understand the work ahead and how to tackle it effectively. Story points were introduced as a psychological buffer to make that collaboration easier—a bit of indirection to avoid the dysfunctions of time-based estimates.

But as we’ve seen, they are not a universal solution. Used thoughtfully, they help teams speak openly about complexity and uncertainty. Used mechanistically, they become just another bureaucratic metric—or worse, a tool of obfuscation.

We’ve explored the landscape of estimation: from story points to ideal days, t-shirt sizes to #NoEstimates. Each has its place. The savvy agile practitioner will choose the right approach for the situation and remain ready to adapt when circumstances change. No single method represents “the One Truth.”

The truth lies in agile principles: individuals and interactions, working software, customer collaboration, responding to change. Choose the method that best supports those principles in your specific context.

For Leaders and Executives

If you’re a leader or executive, here’s a challenge for you: focus on creating an environment of trust and learning. If your teams are locked in endless estimation debates or consistently missing forecasts, resist the urge to mandate a new process or demand “more accuracy.”

Instead, have an open conversation with the teams: what’s getting in their way? How can you help them feel safe to give realistic estimates (or to deliver without them)? Maybe the issue isn’t the estimates at all, but technical debt, unclear priorities, or fear of blame. Solve the right problem.

Remember, the best way to get reliable forecasts is to foster a culture where people can be frank about uncertainty and where learning from mistakes is valued more than meeting arbitrary targets.

For Agile Team Members and Coaches

If you’re an agile team member or coach, here’s your call to action: inspect and adapt your planning approach. Try an experiment in the next quarter:

• If you’ve always used story points, perhaps try #NoEstimates on a small scale and see what happens
• If your story points have effectively turned into hours, openly call that out in retrospective and discuss whether to change your approach
• Introduce the idea of probabilistic forecasting to stakeholders—showing a burn-up chart with a confidence range can be eye-opening to managers used to single-point estimates
• Most importantly, encourage honest dialogue about effort and risk in planning meetings

Don’t let the numbers (points or hours) silence the important nuances. If something is complex or risky, say so explicitly—not just via a higher number.

For Everyone: Stop Putting Lipstick on Pigs

And to everyone: let’s stop putting lipstick on pigs. If something in your agile process feels like the old command-and-control approach in disguise, no amount of agile terminology will make it better. Address it directly.

If your story points are just disguised man-days, own that fact and either change how you use them or adopt a different approach that better serves your needs. If your #NoEstimates experiment is really just pushing estimating effort onto the Product Owner without support, acknowledge that and find a better way forward.

Agile planning should be about transparency, adaptation, and trust. Story points were an attempt to support those values, not an end in themselves. Don’t worship at the altar of any metric—demand results in terms of working software and satisfied customers.

Agile legend Larry Putnam’s research showed enormous variations in productivity across teams (one team’s one hour can be another team’s 2,000 hours), reinforcing that comparing or standardizing estimates across teams is futile. Instead, focus on making each team better than it was yesterday. Measure to learn, not to judge.

A Final Thought

In the end, whether you use story points, T-shirt sizes, no estimates at all, or some other approach, remember the goal: deliver value consistently and sustainably. If your planning approach helps you do that, excellent. If not, be bold enough to change it.

As the Agile Manifesto reminds us, value responding to change over following a plan—that includes changing your approach to planning itself!

So go forth: plan, estimate (or not), and iterate. Keep it real with your team and stakeholders. Have those sometimes uncomfortable conversations about uncertainty and trade-offs—they are far better than comfortable illusions that eventually unravel.

The story points illusion served its purpose as a stepping stone into agile practices. Now it’s time to graduate to a new level of honesty and effectiveness in planning. The next time someone asks for an estimate, give them an answer—but also give them the context, the caveats, and a commitment to keep them informed as you learn more.

Trade the illusion of certainty for the reality of trust-based collaboration. That’s the true agile way.

References

• InfoQ – “How to Tell Your Boss Story Points Are a Terrible Metric” – Discussion of early terminology (“gummi bears” and “NUTs”) and summary that story points indicate capacity, not productivity.
• StackExchange – “Why do we use story points instead of man days?” – Analysis of how story points allow teams to measure improvement without re-estimating and incorporate complexity/risk.
• Vasco Duarte (LinkedIn) quoting Ron Jeffries – “Story points misuse” – Ron Jeffries expresses regret at the misuse of story points and advises to drop them if they aren’t providing value.
• Scrum.org forum – “Normalization of story points between Teams (SAFe)” – Description of how in SAFe, attempts to normalize lead teams to equate 1 point to 1 day automatically.
• Ken Schwaber and James Coplien on normalization – Explanation that story points cannot be standardized across teams and that comparing points between teams is fundamentally flawed.
• Vasco Duarte – LinkedIn Post – Statement that story points were meant to hide information and deliver less information than other metrics.
• InfoQ – “Sizing and Forecasting in Scrum” (#NoEstimates interpretation) – Suggests that one way to implement #NoEstimates is by counting items delivered per sprint for forecasting.
• Tomas Rybing – “The NoEstimates Movement” – Cites W. E. Deming on needing a stable system for predictability, achievable with teams that stay together on one product.
• Jeff Sutherland – “Scrum Points: Why Story Points Are Better Than Hours” – Reports that story point estimation cuts estimation time by 80% compared to traditional methods.
• Atlassian Agile Coach – “Story points vs. hours” – Explains that story points consider complexity, work amount, and uncertainty, and that this abstraction encourages team discussion.
• Atlassian – “Estimation is not a blood-oath” – Frames that an estimate should not be treated as an unbreakable promise.
• InfoQ – “Focus on uncertainty over dates” – Suggests that for complex work, it’s better to manage expectations about uncertainty rather than promising exact dates.