Rolling Waves, Vertical Slices, and WIP Limits

Agentic AI can start more work in minutes than a human can review in hours. It can research, write, test, generate images, transform data, modify code, and delegate follow-up tasks to additional agents in parallel. That is one of its greatest strengths – and one of its most important project-management risks.

A project does not fail only because too little happens. It can fail just as easily because too much is started at the same time, because a long-term plan is overloaded with false precision, or because the team discovers far too late whether the many separate pieces actually form a functioning whole.

The decisive question is therefore not: How many agents can we keep busy in parallel?

It is: How do we shape work so that learning, completion, and control remain faster than the creation of new work?

Three concepts form a particularly strong combination for this purpose:

Rolling Waves determine how far into the future we plan in detail.

Vertical Slices determine which complete, testable part of the system we prove next.

WIP Limits determine how much work may be started but not yet finished at the same time.

Together they create an architecture for agentic projects that depends neither on micromanagement nor on unlimited autonomy. The AI may work quickly. But the geometry of the project prevents speed from turning into uncontrolled breadth.

The real problem is started work

In traditional projects, parallel work was expensive. New employees had to be coordinated, receive access, read briefings, and find meeting time. With agentic AI, those start-up costs fall dramatically. Another research agent, a second reviewer, or three additional variants are only a command away.

The bottleneck therefore shifts.

What becomes scarce is not starting work, but finishing, integrating, and reviewing it.

Consider a simple situation. An agent receives the task of producing three image variants for each of twenty products. Through subagents, a seemingly manageable request can suddenly become dozens of parallel workstreams. Every stream creates files, decisions, status messages, and follow-up questions. Even if the technology works perfectly, the review and integration load can grow faster than the actual learning generated by the work.

Agentic projects therefore need a different baseline rule than many traditional digital projects:

Do not optimize the number of active agents. Optimize the flow of completed, reviewable work.

This is the context in which Rolling Waves, Vertical Slices, and WIP Limits become truly important.

Three tools - three different problems

The three concepts are easily mixed together, even though they solve different control problems.

A project can be strong in one of these areas and weak in the others.

A team might plan cleanly in Rolling Waves while overloading each wave with ten parallel agents. Or it might have a strict WIP Limit but produce only horizontal components that look good individually and still fail when combined. Or it might build an excellent Vertical Slice, then return to six months of task-level preplanning and create a precision illusion that collapses as soon as the first new piece of evidence appears.

The real effect comes from combining the three.

Rolling Waves: not less planning, but more detail where knowledge exists

Rolling Wave Planning is not an excuse for weak planning. It is the opposite: a disciplined response to uncertainty.

The basic idea is simple. The near future is planned in detail. More distant work remains described at a higher level and is refined only when enough new knowledge becomes available.

This produces several planning horizons:

1. Project picture: What is the goal, what is explicitly out of scope, and what effect should be created?

2. Middle horizon: Which larger result areas, milestones, or planning packages will probably be needed?

3. Current wave: Which concrete work packages are being handled now?

4. Next move: Which immediate next action is approved and executable?

A common failure mode in AI project plans is filling all four levels with maximum detail at the same time. AI can generate a 90-day plan with hundreds of tasks, roles, deadlines, and dependencies in seconds. Formally, it looks impressive. Substantively, much of that detail rests on assumptions that have not yet been tested.

The result is planning illusion: a document looks precise even though reality is not yet precise enough to support it.

Rolling Waves accept that a project knows less at the beginning than it will later. They make that uncertainty visible instead of hiding it behind tables.

The detail horizon is a control variable

The important question is therefore not only: What are we planning? It is also: How far ahead do we plan in detail?

A useful detail horizon depends, among other things, on technical uncertainty, probability of change, availability of evidence, dependencies on external systems, cost of incorrect planning, speed at which new information is produced, and reversibility of upcoming decisions.

For a stable, repeatable process, detailed planning may extend relatively far. For an experimental agentic prototype, even next week may be too distant.

That is not a sign of weak project leadership. It is a deliberate calibration of planning resolution.

The more uncertain the future, the coarser its planning may remain – as long as it is clear when and by what evidence it will be refined.

Progressive elaboration needs explicit triggers

Rolling Waves only work if "plan later" does not become "never plan."

Each future planning unit therefore needs a trigger for refinement: a prototype has been tested, a slice reaches the Definition of Done, a key assumption has been confirmed or falsified, a cost range has been clarified, an interface has been technically verified, an external stakeholder has made a decision, or a risk threshold has been reduced.

The next wave is then not planned by calendar reflex, but on the basis of new knowledge.

A useful Wave Review asks:

1. What have we learned since the last planning cycle?

2. Which assumptions are now wrong or more uncertain than before?

3. Which planning packages can now be decomposed meaningfully?

4. What should intentionally remain coarse?

5. Which work should be removed from the next wave, not merely added?

The fifth question matters especially. Agentic systems are excellent at generating new optimization ideas. Mature planning must become equally good at not doing things.

Vertical Slices: prove impact end to end instead of building layer by layer

Rolling Waves structure time. Vertical Slices structure the proof.

A Vertical Slice is a small but functioning end-to-end section of a larger system. It does not have to do everything. It has to demonstrate that the core path actually works.

That distinguishes it from horizontal decomposition.

Imagine a team building an AI-assisted consulting workflow. A horizontal decomposition might look like this: week 1 data model, week 2 prompt library, week 3 user interface, week 4 reviewer logic, week 5 export, week 6 connect everything.

Each layer can report progress. Yet for five weeks, the team still does not know whether the complete flow is viable.

A Vertical Slice would instead build one very small end-to-end path:

one real request → defined input → AI elaboration → review → visible result → export.

Perhaps that slice works for only one use case. That is fine. Its value lies not in breadth, but in proof of viability.

The slice is an executable hypothesis

A good Vertical Slice does not merely answer, "Does the code run?" It tests a project hypothesis.

For example:

If we run this complete core workflow with realistic input, can we produce a usable result within the intended quality, time, and cost constraints?

The slice therefore becomes a learning instrument.

It can answer technical questions: Can the interface be called reliably? Is model quality sufficient? Does the export work?

It can also answer organizational questions: Is the review load sustainable? Can the human understand the output? Is too much rework required? Is the flow plausible for real users?

And economic questions: What are the actual runtime and token costs? How much human time remains necessary? Is the value large enough to justify more development?

A slice should therefore not be understood as a "miniature version of the entire backlog." It is a targeted experiment with end-to-end responsibility.

A slice contract prevents mini-monoliths

Vertical Slices can also expand uncontrollably. "We are testing one core flow" quickly becomes "while we are here, let us also build login, dashboard, analytics, and three role models."

A Slice Contract helps prevent that.

The most important field is often Non-scope. Without it, a Vertical Slice easily turns into a complete product in miniature and loses its learning function.

The right slice size sits between trivial and unreviewable

A slice can be too small.

If it proves only that an agent can generate text, we learn little. The actual integration risks remain hidden.

It can also be too large.

If a slice needs six weeks, twelve tools, and fifty subtasks, we discover far too late which assumption failed first.

A useful slice size therefore does not maximize the amount of finished functionality. It maximizes the ratio of learning gain to effort.

Helpful questions include: Which major uncertainty can we expose with a small end-to-end path? Which interface could block the project later? Which assumption would be expensive if disproven only in three months? What minimum user effect can we observe in reality? Which decision can we make better after this slice than before it?

Decomposition becomes a form of learning design.

WIP Limits: started work is inventory

Vertical Slices tell us what to prove. WIP Limits determine how much of it may remain open at the same time.

WIP means Work in Progress – work that has been started but is not yet finished.

In knowledge work, started work is easy to hide. It exists in open browser tabs, agent runs, branches, chats, review queues, draft files, and half-finished analyses. Agentic systems amplify this problem because they can create new work extremely quickly.

A WIP Limit turns that into an explicit capacity decision.

For example: maximum 2 active slices, maximum 3 open research packages, maximum 1 unreleased technical branch, maximum 4 results simultaneously waiting for review, maximum 2 parallel agent runs with external tool permissions.

The exact numbers depend on context. The logic is broader:

New work is pulled only when real capacity becomes available.

That is the difference between pull and push.

WIP is more than the number of running agents

In agentic projects, simply limiting the number of active agents would be too simplistic.

A single agent can create ten open subtasks. Conversely, five agents can collaborate on one clearly bounded slice.

WIP should therefore be observed at several levels:

This prevents a common thinking error: a team reduces the number of active agents but leaves twenty open work packages sitting in the system. The bottleneck remains.

The WIP Limit test: can the system actually finish everything that is open?

A useful WIP Limit is not based on how much work can be started, but on how much can be completed reliably.

Five questions are particularly useful:

1. How many results can we seriously review per unit of time?

2. How many parallel streams can we keep consistent in the project state?

3. How many open dependencies can we coordinate without constant context switching?

4. How much cost and token consumption are we willing to have active at once?

5. How quickly can we detect when a stream is blocked or no longer useful?

If the answer to any of these questions is "not reliably," the current WIP is probably too high.

Controlled parallelism is not maximum parallelism

Parallelism remains important. Four independent source-research tasks can sensibly run at the same time. Two independent test variants can as well.

Parallelism becomes problematic when work is only apparently independent.

Typical hidden couplings include: all agents depend on the same unstable baseline, several streams write to the same files, all outputs must be reviewed by the same person, a later merge depends on information that may be lost on the way, a decision in stream A changes assumptions in stream B, or all agents consume the same limited tool or token pool.

Controlled parallelism therefore begins with a dependency question:

Which work can genuinely be completed independently – and which work only creates parallel queues?

The goal is not full resource utilization. The goal is better total flow.

Utilization is not a success metric

This may sound counterintuitive. If agents are cheap and available, why not keep them occupied all the time?

Because maximum utilization often creates maximum queues.

A project in which every agent continuously starts something new quickly produces: more open results, more review demand, more context switching, more merge conflicts, more outdated intermediate states, and more work whose value is no longer prioritized.

Agentic productivity should therefore not be measured in "agent hours" or "number of artifacts produced."

Better questions are: How many valuable work items are actually completed? How long do started items remain open? How much rework is created? How many outputs are discarded before use? How quickly do we reach the next defensible project decision?

Finish more. Start less.

It sounds unspectacular. In agentic systems, it is a radical control rule.

Work packages must end in human-readable form

Another advantage of small work packages is comprehensibility.

If an agent works autonomously for hours and then presents only one enormous final state, a review problem appears. The human can see the result, but can no longer reliably reconstruct which assumptions, changes, and decisions led there.

Every relevant Work Package should therefore end with a short completion report.

Such a report can include: package objective, work performed, artifacts created or modified, most important results, open uncertainties, deviations from plan, blocked items, cost or runtime, recommended next action, and whether the package is truly "Done."