Iteration-based and flow-based agile: one fixes the interval, the other fixes the queue

Iteration-based agile fixes the interval. A team commits a set of work to a cycle of fixed length and reviews at the boundary. Flow-based agile fixes the limit instead: no iteration at all, a cap on how much can be in progress, and the next item pulled the moment a slot frees.

One model fixes the interval, the other fixes the queue

Everything else follows from that one decision, so it is worth being precise about it.

An iteration is a fixed container. The Scrum Guide describes sprints as fixed length events of one month or less to create consistency, with a new one starting immediately after the previous one ends. The length is the constant, the contents are the variable, and when the work turns out to be larger than expected it is the scope that gives way rather than the date. That is the whole trick of a time-box: it converts an open-ended queue into a series of comparable periods.

A flow-based system has no such container. What it fixes instead is quantity. A limit on work in progress caps how many items may be under way at any moment, and nothing new starts until something finishes. The constraint is doing the same job the boundary did in the other model, which is to stop a team taking on more than it can complete, but it enforces it continuously rather than once a fortnight.

Dimension	Iteration-based	Flow-based
Fixed	Length of the cycle	Amount in progress
Planning	At the start of each cycle	When an item is pulled
Commitment	A set of items, by a date	A time range, per item
New priority	Waits for the boundary	Enters at the next pull
Measured by	Velocity per iteration	Throughput, cycle time
Delivery	At or after the boundary	Whenever an item finishes

Planning on a date against planning on a vacancy

In an iteration-based team, planning is an event. It happens on a known day, it produces a set of work for the cycle, and its output is a commitment that holds until the boundary. That predictability is what everything downstream is buying: testing knows when work arrives, a sponsor knows which meeting will have news in it, and a stakeholder with a new request knows exactly when it can be considered.

In a flow-based team, planning is triggered by a vacancy. The Association for Project Management describes Kanban as a method for managing work, with an emphasis on just-in-time delivery, and just-in-time is the operative phrase. Nothing is planned until a slot opens, at which point the team takes whatever is now top of the queue. The ordering decision is made at the last responsible moment, on the most current information available, and a request that arrived this morning can be started this afternoon if it deserves to be.

Scheduling in a flow system worries people, because there is no plan to point at. What replaces it is a forecast built from the team’s own record of finished items. A team that knows what its cycle times have actually looked like over the last hundred requests can quote a range with a confidence attached to it, and answer “when will this be done” with an honest distribution rather than a single date somebody made up in a planning meeting. It is a weaker promise about any one item and a considerably stronger one about the hundred.

Velocity measures a batch, throughput measures a stream

The metrics diverge because the units do.

Velocity counts the work completed in one iteration, which means it needs an iteration to exist before it means anything. It is useful precisely because iterations are comparable: fifteen points last cycle and fourteen this cycle is a genuine comparison, since the two periods were the same length. That comparability is also its weakness, because it evaporates the moment the interval moves, and a team shortening its cadence watches velocity drop while nothing about the work has changed. The article on delivery cadence covers what else that rebasing quietly breaks.

A flow-based team reads two numbers instead. Throughput is finished items per week, counted where work leaves the system, so it cannot be inflated by starting more. Cycle time is the elapsed time from starting an item to finishing it, read as a distribution rather than an average, because the average is the one figure that tells you nothing about the request currently sitting in front of an angry customer.

Which one the arriving work is asking for

The choice is decided by the shape of the demand rather than by preference, and there are four questions that settle it.

How predictably does work arrive? A flow-based approach is better when the volume of work fluctuates and the emphasis is on speed and flow. Where arrivals are unpredictable, items differ wildly in size, and the priority order can change in the middle of any week, an iteration plan is a fiction that gets rewritten mid-cycle anyway. Where the intake is steady enough to plan a fortnight of it honestly, the iteration earns its keep.

How badly do you need a fixed feedback point? This is the strongest argument for iterations and the one most often forgotten in the enthusiasm for flow. A boundary is a scheduled moment when the work stops and everybody looks at it. Where the requirement is uncertain, or technically difficult, or where several teams have to align, that guaranteed pause is worth the responsiveness it costs.

How experienced is the team? Iterations carry more scaffolding, and scaffolding helps. Flow looks simpler on a whiteboard and demands considerably more discipline in practice, because there is no boundary to force the conversation, no scheduled retrospective unless somebody schedules one, and nothing but the limit standing between the team and thirty simultaneously open items.

What kind of work is it? The pattern holds across industries more reliably than the frameworks do. Support desks, maintenance queues, incident response, editorial pipelines and clinical triage all take arrivals they did not choose, in sizes they cannot control, and all run better on flow. Feature development, product discovery, regulated submissions and anything with a review gate attached tend to run better on a cadence, because a batch of related work reviewed together is worth more than the same work reviewed piecemeal.

Most teams that have run both end up somewhere in between, and it is a legitimate destination rather than a failure to commit. The common hybrid keeps the cadence for the things a rhythm is good at, the planning conversation, the review and the retrospective, and drops the batch commitment in favour of a pull with a limit. What that produces is a team with a heartbeat and no promise attached to it, which suits a great deal of real work.

What a flow-based organisation changes beyond the team

Most of the searching around this subject is about teams, and most of the disappointment is about organisations.

A flow-based organisation is one that manages work as a continuous stream along the whole route to a customer, rather than optimising each function separately. That is a much larger claim than a team pulling from a board, and the practical test is unforgiving: are the queues between functions visible, and are they limited? A team that pulls smoothly and then hands finished work into a monthly approval gate is a flow-based team inside a batch-based organisation, and its cycle time is set by the gate rather than by anything the team does.

The queues between departments are the difficult part because nobody owns them. Each function is busy, each is locally efficient, and the waiting happens in the spaces between them where no manager has a report showing it. Work sitting in a security review inbox for nine days appears on nobody’s dashboard, because the security team measures its own turnaround from the moment it picks something up. Measuring elapsed time from the customer’s request to the customer’s receipt is what makes those gaps appear, and the number is routinely several times the sum of the touch times.

The same logic climbs to the portfolio. An organisation running forty initiatives with sixty people has a work in progress problem that no team-level board will fix, and the remedy is the identical one: stop starting, start finishing, and cap the number of things in flight so that the ones in flight can actually move. That is a funding decision rather than a delivery decision, which is why it is nearly always harder than anything a delivery team is asked to do.

What neither model decides for you

Both are containers for work, and neither has an opinion about what goes in them.

Neither chooses priority. An iteration plan built from the wrong backlog produces the wrong increment on schedule, and a flow system pulling from the same backlog produces it slightly sooner. Neither improves quality, and both will happily deliver defects at their chosen rhythm. Neither fixes a team that cannot say what “finished” means, and both will make that ambiguity more visible, which is useful but is not the same as solving it.

The failures blamed on the model are almost always something else wearing its clothes. Work spilling over an iteration boundary is a sizing problem, and shortening the iteration makes it worse. A flow system with unpredictable cycle times usually has no limit, or has a limit everyone agreed to ignore. A team that cannot forecast under either approach is generally being interrupted by work that never reaches the board at all.

Which suggests the honest way to choose. Pick the one whose constraint your team will actually respect, run it unchanged for long enough to generate a few cycles of evidence, and change one thing at a time afterwards. The comparison that matters is not iteration against flow in the abstract. It is the discipline you will genuinely hold against the discipline you would like to think you would.