Beyond PI Planning

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 and align on 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.

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

How do we replace quarterly planning with continuous pull?

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:

• Continuous, evidence-driven discovery
• Clear, explicit readiness criteria
• Pull-based execution
• Stable, predictable delivery throughput

By contrast, PI Planning emphasizes:

• Timeboxed discovery
• Large planning batches
• 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 discovery workflow might include stages such as:

• Idea Funnel: Placeholder for all incoming ideas, opportunities, and requests. This stage ensures that potential work is captured, categorized, and assessed for strategic relevance before entering deeper evaluation.
  Items should only move from the Idea Funnel into Assessment when there is sufficient evidence of strategic relevance, economic value, or opportunity timing to justify additional discovery effort. This policy helps prevent excessive discovery inventory and ensures scarce refinement capacity is focused on economically meaningful opportunities.
• Assessment: Evaluate business value, strategic impact, technical feasibility, and potential constraints. This collaborative activity helps determine whether the work justifies scarce delivery capacity.
  Items should only progress into Refinement when there is sufficient confidence that the opportunity is strategically worthwhile, technically feasible, and likely to justify implementation effort. Work that lacks clear value, alignment, or feasibility should be removed from the workflow rather than accumulating as discovery inventory.
• Refinement: Define the details required for successful implementation. Features are clarified, dependencies identified, and work sized appropriately to enable stable flow through the delivery system.
  Items should only move into the ART Backlog when they meet an agreed Definition of Ready. At a minimum, this includes clear business intent, appropriate flow sizing, manageable dependencies, and sufficient clarity for delivery teams to begin implementation without significant additional discovery effort.
• Ready (ART Backlog): This is the final state of the discovery workflow. It represents validated intent, economic prioritization, and technical readiness for implementation.
  Items in this state are flow-ready and can be pulled into delivery when capacity becomes available. The Ready backlog should remain actively governed and economically ordered to ensure that delivery teams continuously pull the highest-value work available.

Each stage has:

• Explicit entry and exit criteria
• WIP limits that constrain over-commitment

The SAFe literature does indeed recommend 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 a PI Planning event, 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 a clear boundary between discovery and delivery, and items there have sufficient readiness for pulling into the delivery system.

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.

What is the ideal depth of the ART Backlog?

In a flow-based operating model, the ideal depth of the ART Backlog is:

• deep enough to maintain uninterrupted flow
• but shallow enough to remain economically relevant, governable, and continuously refined.

A large backlog creates many of the same problems as excessive WIP:

• stale priorities
• outdated assumptions
• hidden inventory cost
• false certainty
• refinement waste
• prioritization collapse

In Lean terms backlog inventory is still inventory, and inventory creates delay.

In Practical Terms, for an ART-sized system, the ideal “Ready” backlog depth is probably something like 1–2 months of flow-ready work. Not 6 – 12 months, or entire roadmaps. The deeper the backlog the more speculative the prioritization becomes.

Suggested ART Backlog Policy

The Ready ART Backlog should contain enough validated and refined work to maintain uninterrupted delivery flow, but not so much that prioritization becomes speculative or refinement effort is wasted. As a guideline, Ready inventory should typically represent a limited future delivery horizon relative to observed ART throughput.

Example:

If an ART reliably completes 8 features/month, then perhaps 12–16 ready features is sufficient. (Yes, that’s a WIP Limit).

Beyond that:

• economic relevance decays
• assumptions become stale
• refinement waste increases

Furthermore, when features are consistently sized for flow (1-2 sprints max per feature), backlog order and delivery order begin to converge naturally. Once feature size variability is controlled, backlog ranking becomes a much stronger predictor of delivery order. This is one reason feature sizing discipline is so important in flow-based systems. It is not simply a refinement exercise. It is a prerequisite for stable forecasting, pull-based prioritization, and predictable throughput.

---

Designing ARTs for Flow

I’ve written at length on this topic, for example: ART Design – Organizing Around Value

Getting the right organizational structure in place is a critical prerequisite for flow-based delivery. Traditional functional silos create flow-impeding dependencies between teams. A value stream mapping exercise can help ensure teams are focused on customer value delivery, have clear missions, and can operate with minimum dependencies. The best delivery performance in terms of throughput and delivery cycle time is achieved with small, autonomous, cross-functional teams that can independently deliver value to a customer – deployable product features and capabilities.

When an ART is designed in this way it can achieve a stable, predictable delivery throughput. This capability is essential for forecasting delivery, and provides more sound basis than deterministic planning.

This structure enables us to move away from dependency management to dependency reduction.

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

Throughput stability depends on dependency reduction.

---

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 (cycle 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.

The Role of the ART Sync in a Pull-Based Model

In a pull-based operating model, the role of the ART Sync changes fundamentally. It is no longer a forum for coordinating execution against a fixed PI plan. Instead, it becomes a control event focused on maintaining stable flow through the delivery system.

The ART Sync operates as the controller within the system. Its purpose is to inspect operational flow signals such as work-in-progress, feature aging, blocked work, and throughput stability, and to determine whether corrective action is required. Rather than asking, “Are we on plan?”, the ART asks: “Is work flowing predictably through the system?”

This changes both the nature of the discussion and the actions that result from it. Attention shifts away from status reporting and toward system behavior. Aging features, overloaded teams, unstable throughput, or excessive dependencies become signals that the system is under stress and requires intervention.

The purpose of the ART Sync is not to manage every work item centrally. It is to maintain the conditions required for stable flow. Corrective actions may include re-sequencing work, reducing work-in-progress, swarming blocked features, resolving dependency bottlenecks, or temporarily slowing intake into the system.

In this model, governance becomes operational rather than ceremonial. The ART Sync acts as a lightweight feedback and control mechanism that continuously regulates flow across the ART.

A planning-based ART manages delivery through coordination. A flow-based ART manages delivery through flow-control.

The Role of ART Demos in a Pull-Based Model

Traditional PI System Demos often serve multiple purposes:

• validate progress against PI commitments
• demonstrate delivery against the plan
• provide stakeholder reassurance
• synchronize understanding across the ART

In a flow-based system, the emphasis shifts away from: “Did we deliver what we planned?” , toward: “What has the system actually delivered?”

In a flow-based operating model, the ART Demo acts as a product feedback mechanism. Completed features are demonstrated to stakeholders, feedback is gathered, and insights are fed back into backlog prioritization and discovery activities. This creates a continuous learning loop between delivery outcomes and future investment decisions.

While the ART Sync regulates operational flow, the ART Demo regulates product learning and strategic alignment.

Together, these feedback loops allow the system to continuously adapt both operationally and economically.

It becomes:

• an operational feedback mechanism
• a learning mechanism
• a validation mechanism

Importantly: Demos Become More Continuous. We may still maintain a regular ART-level demonstration cadence, perhaps every 2 weeks or monthly

But features themselves can be demonstrated as they complete, rather than waiting for PI boundaries

Flow-based delivery does not eliminate demonstration and feedback. It increases their importance. What changes is the purpose. Demonstrations no longer validate adherence to a plan. They validate delivered outcomes and generate learning.

---

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 4 key elements:

This shifts the organization from:

• Planning cadence → flow cadence
• Event-driven alignment → continuous, system-driven alignment

---

This is a simpler operating model that can replace the need for PI Planning.

1. Discovery regulates intake
2. The ART Backlog maintains alignment
3. ART structure stabilizes throughput
4. Flow control governs execution

---

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.

Get a Free Flow Review

If your delivery system feels overloaded, slow, or coordination-heavy, a short review can help identify where flow may be breaking down.

This is a practical, low-risk way to explore whether a deeper diagnostic or consulting engagement would be useful.

Take a Free Flow Health Assessment

 

---

Leave Me a Comment