Beyond PI Planning

PI Planning, as commonly practiced, often functions as a form of Big Up-Front Planning (BUFP).

PI Planning is a key event in the SAFe Scaled Agile Framework where multiple development teams—an entire Agile Release Train (ART), along with business stakeholders—come together (physically or virtually) to create a delivery plan for the next PI timebox (8-12 weeks). The event typically takes two full days (more when travel is involved), during which most development activity is effectively suspended.

Teams stop delivering in order to plan delivery.

My core thesis is this: when an organization has a well-designed upstream Discovery Kanban, PI Planning becomes largely redundant. In such systems, the ART Backlog already represents alignment, prioritization, and readiness, enabling teams to pull work continuously rather than commit to speculative plans made weeks in advance.

Why PI Planning Behaves Like Big Up-Front Planning

PI Planning was not intended to be BUFP. However, in practice, it often becomes exactly that.

Several structural characteristics consistently drive this outcome:

  • Teams plan large batches of work every quarter.
  • Decisions are forced into a fixed 8–12 week cadence.
  • Discovery and prioritization accelerate because the event is approaching, not because learning or evidence demands it.
  • Teams commit to scope based on assumptions that are frequently invalidated within weeks.
  • Dependencies are “managed” rather than reduced or eliminated, locking in coordination costs.
  • The appearance of certainty—objectives, plans, dependency boards—masks underlying uncertainty.
  • Predictability is achieved by constraining change, not by improving flow.

When priorities shift or technical challenges emerge mid-PI (which they inevitably do), the organization pays twice:

  1. First, for the PI Planning event itself.
  2. Again, through unplanned replanning, work-in-progress churn, and broken commitments.

PI Planning doesn’t eliminate uncertainty—it institutionalizes it into a fixed planning rhythm.

Flow Is a Continuous Property, Not an Event

Agility does not emerge from periodic synchronization events.
It emerges from continuous decision-making close to the work.

Flow requires:

  • Small batch sizes

  • Frequent reprioritization

  • Clear, explicit readiness criteria

  • Pull-based execution

By contrast, PI Planning emphasizes:

  • Large planning batches

  • Timeboxed commitment windows

  • Push-based alignment

  • Coordination over optimization

This creates a structural mismatch.

PI Planning optimizes for coordination efficiency; flow optimizes for value throughput.

The Role of an Upstream Discovery Kanban

An effective upstream Discovery Kanban:

  • Makes strategy-to-execution flow visible

  • Enables continuous, evidence-based prioritization

  • Enforces explicit policies for readiness

  • Encourages hypothesis-driven discovery

  • Limits work-in-progress before development starts

A typical upstream flow might include stages such as:

  • Funnel / Options

  • Discovery

  • Validation

  • Refinement

  • Ready (ART Backlog)

Each stage has:

  • Explicit entry and exit criteria

  • WIP limits that constrain over-commitment

The SAFe literature does say that a Kanban System should be used to manage, shape and refine the ART backlog – prior to PI Planning. In concept, this is functionally equivalent to what many practitioners would call a Discovery Kanban. However in practice, across many organizations I’ve worked with, that Kanban System is:

  • Not implemented at all

  • Implemented superficially

  • Treated as an administrative queue rather than a learning system

More often than not, discovery work is compressed into the weeks leading up to PI Planning, driven by the calendar rather than by evidence or learning. Features are “prepared” just enough to survive the planning event, not to enable flow. When discovery is weak, PI Planning is forced to compensate—and that’s when it starts to look like Big Up-Front Planning.

The ART Backlog as the “Last State” of Discovery

In this model, the ART Backlog is the output of upstream discovery.

It represents:

  • Validated intent

  • Economic prioritization

  • Technical readiness

  • Shared understanding across teams

When upstream Kanban is functioning well, features entering the ART Backlog are:

  • Small enough to flow

  • Clear enough to estimate when pulled

  • Valuable enough to justify investment

  • Ready enough to minimize surprises

Where PI Planning attempts to create alignment, upstream Kanban reveals it continuously.

Pull-Based Development vs Push-Based Planning

Pull-based model (Kanban-enabled):

  • Teams pull features from the ART Backlog when capacity is available

  • Priorities can change without disrupting in-flight work

  • Flow metrics (lead time, throughput, WIP) drive decisions

  • Alignment is persistent, not episodic

Push-based model (PI Planning-centric):

  • Work is pushed into the system in large batches

  • PI Planning begins when ownership of the ART Backlog is essentially handed off (pushed) from Product Management to the delivery system

  • Commitments are made far ahead of execution

  • Changes are treated as exceptions

  • Metrics emphasize plan adherence over flow (ART Predictability Measure)

Many organizations struggle because they:

  • Never let go of the plan

  • Keep “managing” execution through planning artifacts

  • Treat deviation as failure rather than signal

Flow-based focus:

  • Product Management to focus on what matters next

  • Teams to focus on finishing and learning

  • ART Sync to focus on flow exceptions

  • Leadership to focus on decisions, not updates

PI Planning is the point at which intent is handed to the delivery system. From that moment on, flow—not the plan—must be allowed to govern execution.

Pull systems assume change; push systems attempt to suppress it.

Dependency Management vs Dependency Reduction

PI Planning often excels at visualizing dependencies—but visualization alone does not reduce their cost.

Dependency boards make dependencies visible, not harmless.

True agility comes from:

  • Smaller features

  • Decoupled architectures

  • Cross-functional teams

  • WIP limits upstream

Upstream Kanban supports this by:

  • Forcing dependency conversations earlier

  • Making architectural constraints visible sooner

  • Preventing oversized, dependency-heavy features from entering development

When PI Planning Might Still Make Sense

To be clear, this is not an argument that PI Planning is always wrong.

PI Planning may still be useful as a transitional mechanism when:

  • Organizational maturity is low

  • Upstream discovery is weak or nonexistent

  • Architecture is tightly coupled

  • Leadership requires a transitional alignment mechanism

Even then, it should be treated as a temporary coordination scaffold, not a permanent operating model.

PI Planning can compensate for weak flow—but it cannot replace it.

Towards a More Flow-Oriented Alternative

A more flow-centric approach emphasizes:

  • Continuous discovery via Upstream Kanban

  • Economic prioritization at the portfolio level

  • The ART Backlog as the single source of truth

  • Continuous pull into development

  • Lightweight, frequent synchronization (not quarterly events)

This shifts the organization from:

  • Planning cadence → flow cadence

  • Event-driven alignment → continuous, system-driven alignment

Closing Thoughts

If agility is the ability to respond to change, then any practice that delays decision-making into fixed planning windows deserves scrutiny. PI Planning may create the comfort of alignment—but flow creates the reality of agility.

In a pull-based ART, teams don’t plan large batches of work every quarter; they continuously pull the next most valuable, ready feature from the ART Backlog and deliver it using standard Scrum or Kanban practices.

Nothing here violates SAFe principles:

  • Apply systems thinking

  • Make value flow without interruptions

  • Decentralize decision-making

  • Base milestones on objective evaluation

In fact, this model arguably aligns more closely with SAFe’s stated principles than how PI Planning is commonly practiced.

Scroll to Top