The Problem with PI Planning and the Truth About Agile Metrics

Part 2 of the “Why Agile Metrics Can Be Misleading” Series

The Real Cost of Ritual

Agile promised to make software delivery more adaptive, more collaborative, and more focused on outcomes. But for many teams, the ceremonies and metrics intended to support those goals have become rigid rituals—followed because they’re expected, not because they work.

Nowhere is this more evident than in Program Increment (PI) Planning.

PI Planning is meant to foster alignment. It promises shared priorities, early risk identification, and structured planning at scale. But when it’s treated as a tool for certainty—rather than collaboration—it quickly turns into a high-stakes forecasting exercise. Teams are pulled into multi-day sessions, expected to estimate and commit to weeks of work in advance, even as the ground shifts beneath them.

And that’s just one of many examples of how Agile metrics and rituals, when misused, begin to erode the very agility they aim to enable.

In this second part of the series, we’ll examine how techniques like PI Planning, story points, and velocity tracking often create the illusion of progress and predictability—while silently undermining adaptability and trust. These are not bad tools, but their impact depends entirely on how they’re used.

In Part 3, we’ll shift focus from critique to solution: the practical, value-driven metrics that support true agility and better decision-making.

The PI Planning Illusion—Predictability at Any Cost

PI Planning, or Program Increment Planning, is one of the most widely recognised rituals in scaled Agile frameworks. Done right, it can bring teams together, align them on shared goals, and provide clarity on upcoming work. But too often, PI Planning becomes a ritual focused on predictability rather than value.

We’ve seen it ourselves. Teams pulled into multi-day planning sessions, expected to map out their work in detail for the next 8 to 12 weeks. Walls (or virtual whiteboards) filled with sticky notes, each representing a user story or feature, each assigned a set of story points. Managers watch eagerly, hoping this process will provide a clear view of what will be delivered and when.

But beneath the surface, something is wrong.

The Problem with Predictive Planning

At its core, PI Planning is meant to be a collaborative exercise—an opportunity for teams to align on priorities and dependencies. But when treated as a predictive planning tool, it becomes a problem:

• A False Sense of Certainty: Teams are expected to plan out detailed work for the next quarter, despite constant change. When reality inevitably diverges from the plan, teams are forced to re-plan or scramble to meet commitments made weeks ago.

• Commitment Over Adaptability: Teams feel pressured to deliver the exact scope they planned, even if priorities have changed. Rather than being responsive to user feedback, they are stuck executing a pre-defined script.

• Wasted Time and Effort: Teams spend hours (or even days) debating estimates and dependencies, only for many of these plans to become obsolete within weeks.

We’ve seen this happen in real organisations, where a carefully crafted PI Plan is treated like a contract, and teams are judged based on how closely they match the planned velocity. In one case, a team we worked with was praised for delivering 95% of their planned work in a PI. What went unnoticed was that the team had rushed to complete low-value stories just to meet their target, leaving important but complex features unfinished.

The Folly of Standardised Estimates

PI Planning also exposes another common mistake—attempting to standardise estimates across teams. In an effort to maintain consistency, organisations try to align teams on a single definition of story points, a single estimation scale. But this standardisation is a waste of time.

• Context Matters: A five-point story for one team may be a two-point story for another, depending on their experience, tools, and domain knowledge.

• Skills Differ: Teams with different skills or expertise will naturally estimate tasks differently.

• Forced Consensus Stifles Productivity: Instead of focusing on delivering value, teams spend time debating how their estimates align with those of other teams.

As a result, what should be a collaborative planning exercise becomes a bureaucratic process of estimation alignment.

The Truth About PI Planning: It’s About Alignment, Not Certainty

But it doesn’t have to be this way. When done right, PI Planning is not about predicting the future—it’s about aligning teams on a shared understanding of goals, priorities, and dependencies. The most effective PI Planning sessions we’ve seen focus on:

• High-Level Goals: Teams align on what they are trying to achieve, rather than committing to specific story points or tasks.

• Flexible Backlogs: Teams understand that priorities may shift, and they have the freedom to adjust as they learn.

• Collaborative Problem-Solving: Teams use PI Planning to identify and address dependencies, not to micro-manage work.

• Capacity as a Guide, Not a Rule: Teams plan based on their historical throughput, not on inflated estimates.

Flow Over Capacity: A Better Way to Plan

When planning becomes a proxy for predictability, teams are often pushed to operate at or near full capacity. It feels efficient on paper—everyone fully allocated, all hands busy. But this approach treats software delivery like a factory line, not a creative, adaptive process.

The reality is that high-capacity systems are fragile. They leave no room to absorb change, recover from setbacks, or explore better solutions. Teams operating at 100% capacity are often the slowest to respond when priorities shift—because they’re already overloaded.

The better alternative is to plan for flow, not utilisation.

Why Flow Matters More Than Capacity

Flow is about how smoothly and consistently work moves through your delivery system. It prioritises outcomes over occupancy. When you optimise for flow:

• Bottlenecks become visible. You can see where work is getting stuck—code reviews, QA handoffs, product feedback—and act accordingly.

• Slack becomes a feature, not a bug. Teams can respond to surprises, explore improvements, or resolve technical debt without derailing a sprint.

• Small batches reduce risk. Delivering smaller slices of value reduces coordination overhead and makes feedback loops faster.

• System health improves. Teams spend less time context switching and more time finishing what they start.

What Planning for Flow Looks Like in Practice

• Visualise Work as a Stream: Use Kanban or flow-based boards to track work from request to delivery—not just from “to do” to “done” in a sprint.

• Limit Work in Progress (WIP): Set explicit WIP limits per person or team to encourage focus and completion over multitasking.

• Measure Flow Efficiency: Track the ratio of active work time to total elapsed time. A system with low flow efficiency often hides excessive queueing or waiting time.

• Design for Slack: Reserve team capacity for unplanned work, bug triage, or emergent opportunities. This is not waste—it’s agility in action.

• Use Capacity as a Guide, Not a Target: Historical throughput tells you how much the team tends to deliver. Use that as a starting point—not a quota to hit.

By shifting from capacity-driven to flow-driven planning, teams create space to breathe, adapt, and deliver reliably—even in the face of change. This is what agility was meant to look like.

PI Planning can be a valuable practice, but only when it aligns teams—never as a tool for rigid, predictive planning.. We’ll dive deeper into this concept of flow over capacity in a future post.

The Dark Side of Traditional Agile Metrics

Agile metrics are intended to guide teams, helping them understand their pace and plan future work. And for a long time, I was a firm believer in many of them. I’ve championed techniques like velocity tracking and commitment rates, confident that they would bring clarity and drive continuous improvement.

But over time—and through hard-earned experience—I’ve come to see the flaws more clearly. These metrics, even when well-intentioned, often drive unhealthy behaviours. They distort the very Agile principles they’re meant to support, shifting focus away from outcomes and toward appearances. Used carelessly, they can create pressure, encourage gaming, and erode trust between teams and stakeholders.

Story Points: From Estimation to Obligation

Story points were never meant to measure time. They were designed to measure relative effort. But somewhere along the way, they became equated with developer hours.

We’ve witnessed situations where managers—often under pressure to deliver on fixed timelines—push for a direct conversion:

• “A three-point story equals six developer hours.”
• “If we can do ten points per sprint, we’ll complete thirty points in three sprints.”

But this conversion misses the point entirely. Story points are inherently relative and contextual. A five-point story in one sprint may not equate to a five-point story in the next. Different teams interpret story points differently, based on their skills, experience, and context.

A 2019 survey by VersionOne found that nearly 40% of Agile practitioners felt pressured to convert story points to hours, despite knowing it was inherently flawed (VersionOne State of Agile Report). This practice not only distorts planning but also leads to a culture where developers feel they must hit an arbitrary point total, rather than focusing on value.

The Problem with Converting Poker Points to Hours

One of the most persistent issues we see is when organisations attempt to standardise story points as equivalent to developer hours. This usually comes from well-meaning managers or departments that want predictability. They ask questions like:

• “If one story point equals three hours, how many points can we deliver in a week?”
• “Why did a five-point task take longer than expected?”

This desire for conversion undermines the entire premise of story points as a relative measure. It creates a toxic environment where estimates become promises. When developers fail to hit those artificially created targets, it’s seen as a failure—leading to mistrust and burnout.

In one particularly problematic case, a client organisation tried to standardise their teams on the basis that one story point should always equal three hours of work. Teams quickly learned to pad their estimates to avoid scrutiny. Instead of fostering transparency, it bred a culture of estimation inflation and distrust between teams and management.

Why This Approach Is So Problematic

1. It Ignores Variability: Story points account for effort, complexity, and uncertainty—not a fixed number of hours.
2. It Creates False Predictability: Converting points to hours suggests a level of precision that doesn’t exist.
3. It Encourages Estimation Inflation: Teams will naturally increase point values to meet arbitrary time expectations.
4. It Discourages Honest Conversations: Teams are less likely to openly discuss challenges if their estimates are treated as commitments.

Agile metrics, when used correctly, can offer valuable insights. But when treated as absolute measures of productivity, they can distort priorities, breed distrust, and ultimately hinder progress. The key is to understand the limitations of these metrics and use them as guides—not as targets to hit at any cost.

Velocity: The Misleading Race

Velocity measures the number of story points completed in a sprint. In theory, it’s a useful way to track how much work a team can handle. In practice, it’s often weaponised.

When velocity is treated as a performance metric, teams feel pressured to inflate their story points to maintain or increase their “speed.” This creates a race to complete more points, even if it means cutting corners or inflating estimates.

We’ve seen teams where velocity becomes the single most important indicator of success, leading developers to pad their estimates just to keep the numbers looking good. The result? Velocity keeps climbing, but quality and customer satisfaction drop.

Burndown and Burnup Charts: The Illusion of Progress

Burndown and burnup charts are meant to visually track progress within a sprint or over multiple sprints. In theory, they provide a clear picture of how much work remains. But these charts can be easily manipulated—by inflating story points, breaking tasks into smaller increments, or pushing low-value work just to make the chart look good.

One team we worked with was praised for their smooth burndown charts, but a deeper look revealed that they were breaking larger stories into smaller sub-tasks just to show consistent progress. The result? A misleading chart that suggested consistent delivery, even though real progress was uneven and unpredictable.

Commitment Rate: The Overcommitment Trap

Commitment rate measures how much of the planned work a team completes within a sprint. While it can highlight issues with planning accuracy, it often leads to overcommitment. Teams, eager to appear productive, take on more work than they can realistically complete.

A few engineering managers we’ve worked with have admitted that their teams would routinely inflate estimates before sprint planning. The reasoning? If they couldn’t hit their commitment rate, they’d at least have a buffer to avoid looking unproductive and create slack for important house-keeping and operational improvement tasks.

Conclusion

PI Planning, story points, and velocity tracking aren’t inherently bad—but the way they’re often used misses the point. When these tools become rigid rituals or targets in themselves, they start to shape behaviour in unhelpful ways. Teams optimise for visibility rather than value. Planning becomes performance theatre. Estimation becomes a shield against uncertainty instead of a tool for understanding it.

These practices don’t need to be abandoned—but they must be reframed.

Coming Up Next

In Part 3: The Agile Metrics That Actually Matter (and How to Use Them), we’ll explore the metrics that cut through the noise—throughput, cycle time, lead time, flow efficiency, and quality. More importantly, we’ll show how to use these signals to guide better decisions, and how to help your team shift from chasing metrics to delivering meaningful outcomes.

---

About the Author

Tim Huegdon is the founder of Wyrd Technology, a consultancy specialising in helping teams achieve operational excellence through pragmatic, value-driven Agile practices. With extensive experience in software engineering leadership, Tim has guided teams across multiple industries to break free from misleading metrics and focus on what truly matters—delivering value.