What Does “Pulling Work Continuously” Actually Look Like?

In my previous article, I argued that 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.

A natural follow-up question is: what does “pulling work continuously” actually look like in practice?

The short answer is that it looks far less radical than many people assume. It does not require abandoning Scrum, inventing a new framework, or
operating without alignment. In fact, it can feel simpler and more disciplined than traditional PI Planning.

1. The ART Backlog as a Pull Queue (Not a Plan)

In a pull-based model, the ART Backlog functions as a prioritized queue of ready work, not a quarterly delivery contract.

Key characteristics of this backlog:

  • Ordered by economic priority (e.g., WSJF or equivalent)
  • Features meet explicit “Ready” criteria
  • Dependencies are identified and minimized upstream
  • Feature size is constrained to enable flow

Nothing is assigned to teams in advance. There is no pre-commitment to a fixed set of features for a timebox.

2. The Pull Trigger: Capacity Becomes Available

A pull is triggered when capacity becomes available at the ART level—for example, when a team completes a feature or drops below a WIP limit.

At that point:

  • The next highest-priority feature at the top of the ART Backlog is pulled
  • No PI boundary is required
  • No large replanning event is needed

This is directly analogous to how teams pull stories from a sprint backlog—but applied one level up, at the feature level.

3. Just-in-Time Feature Refinement

Once a feature is pulled, Product Management and the team collaborate to refine it just enough for execution:

  • Confirm scope and intent
  • Split the feature into sprint-sized stories
  • Clarify acceptance criteria
  • Surface any remaining risks or dependencies

This is rolling-wave planning, not big up-front decomposition. Importantly, the feature has already been validated economically and conceptually upstream.
Only execution-level detail is added at this stage.

4. Delivery via Standard Scrum or Kanban

From here, teams work exactly as they do today.

Scrum teams:

  • Pull stories into Sprint Planning
  • Deliver incrementally
  • Inspect and adapt every sprint

Kanban teams:

  • Pull stories continuously
  • Use WIP limits and flow metrics

The key difference is not how teams work, but what they are pulling from: a continuously replenished ART Backlog rather than a PI plan.

5. Synchronization Without PI Planning

Coordination and alignment still exist, but they are lighter-weight and continuous:

  • Ongoing backlog refinement across teams
  • System demos at natural integration points
  • Targeted dependency coordination when needed

Instead of asking, “Are we still on plan?”, the central question becomes:

“Is the backlog still ordered correctly?”

6. What Happens When Priorities Change?

This is where the pull-based model shows its strength.

When a new high-priority feature emerges:

  • It enters the upstream Discovery Kanban
  • It is validated and refined
  • It moves to the top of the ART Backlog
  • It gets pulled next

There is no PI replanning, no broken commitments, and no disruption to in-flight work.

7. What Replaces PI Objectives?

Rather than PI Objectives, teams and leaders focus on flow-based measures:

  • Throughput
  • Lead time
  • WIP stability
  • Business outcomes per feature

The commitment shifts from “we will deliver these features this PI” to:

“We will continuously deliver the highest-value work the system can handle.”

8. What This Requires to Work

For continuous pull to succeed, several conditions must be in place:

  • A real upstream discovery system (not just a queue)
  • Explicit “Ready” policies for features
  • Small feature sizes
  • An architecture that supports decoupling
  • Leadership willingness to let go of long-range scope commitments

Without these, PI Planning becomes a necessary crutch. With them, it becomes optional.

Closing Thought

In a pull-based ART, teams do not 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.

Flow does not come from better planning events. It comes from better systems.

Scroll to Top