How would you decide between timeboxed iterations and continuous flow for a given team?
answer
- Look first at how the work arrives
- A batch of items, or one item
- Unplanned arrivals break a frozen batch
- Cadence and batch are separable choices
basics
~20 sDecide by how the work arrives. A timeboxed iteration suits work that can be batched and held stable for its length; continuous flow suits work that arrives unpredictably and must be reordered daily. An interrupt-driven team cannot protect a batch.
solid answer
~50 sThe two differ in **what is committed, and when**. An iteration commits a batch up front and holds it for a fixed length, which buys a rhythm, a shared goal and a natural point to inspect and adapt. Flow commits one item at a time as it crosses the commitment point, which buys responsiveness and leaves no batch to protect. So the choice turns on the arrival pattern of the work: if items chosen on Monday are still the right items on Friday, the batch is cheap and the rhythm is worth having; if a third of the period's work arrives mid-period and genuinely cannot wait, every interruption becomes a renegotiation and the timebox is fiction. The senior addition is that **cadence and batch are separable** — a flow team can keep regular selection, demonstration and improvement sessions without committing a batch at all.
go deeper
Know the difference in one sentence: iterations commit a batch of work for a fixed period, flow commits one item at a time as capacity frees. Both deliver in small pieces and both run on feedback.
Explain what each model assumes about arriving work, and what a mid-period arrival does to each. Be able to say why an interrupt-heavy team struggles to hold a batch stable for the whole length of a period.
An interviewer wants judgement backed by evidence: what you would look at in the team's own history — how much arrives unplanned, how often the agreed set was rewritten — before recommending either model, and how you would run the change.
Own the separation of cadence from batch and the organisational cost of the choice. Partners and neighbouring teams plan around a beat, so keep the rhythm even when you drop the batch, and change model only when the work's arrival pattern has genuinely changed.
## Two shapes of commitment Both models deliver in small pieces and both run on feedback. What separates them is the **unit of commitment**. **Iteration-based delivery** commits a batch. At the start of a fixed period the team agrees a set of items and a goal for the period, then holds that set stable until the period ends. The batch is the planning unit, the forecasting unit and the inspection unit all at once. **Flow-based delivery** commits one item at a time. There is no batch: an item becomes an undertaking when it is pulled across the commitment point, and the next selection happens whenever capacity frees. Cadences may still exist, but nothing is promised in blocks. | | Iteration-based | Flow-based | |---|---|---| | Unit of commitment | a batch, for a fixed period | one item, at the moment of pull | | What starts work | the period beginning | free capacity at a stage | | A mid-period arrival | waits, or breaks the batch | is ordered into the queue like anything else | | Basis of a forecast | the batch and recent output | how long comparable items have actually taken | | What breaks it | frequent unplanned arrivals | no rhythm, and drifting priorities | ## What the choice actually turns on Not preference, and not fashion. Five questions, in rough order of weight: 1. **How does work arrive?** If items can be chosen on Monday and are still the right items on Friday, a batch is cheap. If a substantial share of each period arrives mid-period and genuinely cannot wait, the batch is fiction and defending it costs more than it buys. 2. **What does making a new arrival wait actually cost?** For planned product work, a few days of waiting costs almost nothing. For an operational or customer-facing queue, the waiting *is* the damage. 3. **Does anyone outside the team need a fixed rhythm?** Other teams, partners and stakeholders plan around a predictable beat. That is an argument for a cadence — not necessarily for a batch. 4. **Can the team hold a boundary?** An iteration only works if somebody will say "that goes in the next period". A team without the standing to say it runs a batch that is rewritten every second day, which is the worst of both models. 5. **What are the dependencies?** A team feeding, or fed by, a team on a fixed rhythm inherits some of that rhythm whatever it does internally. ## A worked comparison The eleven-person team on a hotel housekeeping app splits naturally in two. Five people handle the operational queue: property-side incidents, urgent data corrections, questions from hotels going live. Over one fortnight, 34 of the 52 items they handled were unknown when the fortnight began. Any batch agreed on day one would have been rewritten within about two days, and the ritual around it would be pure overhead. They run flow: a short queue of options, one item pulled at a time, an explicit commitment point so the hotels get a straight answer about what is actually being worked on. Six people build planned product work. Over the same fortnight, 3 of their 41 items were unplanned. A batch survives easily, a shared goal genuinely focuses them, and a fixed period gives the partner integration deadline a natural checkpoint. They run iterations. Both halves keep the same weekly demonstration, because the stakeholders want one beat, not two. ## Cadence is not the batch The commonest mistake in this discussion is treating "iteration" and "regular cadence" as one choice. They are separable, and separating them is often the strongest answer available: - Keep a regular **selection** conversation — that is a replenishment cadence. - Keep a regular **demonstration** — that is a delivery and feedback cadence. - Keep a regular **improvement** conversation — that is an inspection cadence. - Drop only the **batch**: pull items one at a time against capacity. What you give up by dropping the batch is the single shared goal that a period-long commitment creates. If the team needs one, state a goal for the period explicitly and let flow deliver against it; a goal does not require a frozen list. ## What each choice costs you - **Iterations** cost responsiveness inside the period, and they tempt a team into treating the period end as a deadline, which produces an end-of-period rush and quality paid for silently. They also cost real time in planning each batch. - **Flow** costs the rhythm and the shared goal unless you deliberately keep them. It also demands more discipline: with no period boundary forcing the conversation, ordering, replenishment and improvement must be scheduled on purpose or they quietly stop happening. - **Switching** costs credibility. A team that changes model every few months teaches everyone around it that its commitments are provisional. Change when the arrival pattern of the work has genuinely changed, and say that is the reason.
- Stakeholders want a date but the team runs flow. What do you give them?A forecast built from how long comparable items have actually taken, expressed as a range with a confidence rather than a single day, plus a commitment point they can see: nothing is promised until it is pulled. That is usually more honest than a date derived from a batch everyone expected to renegotiate. Say what would invalidate the forecast — scope growth, or a new stream of urgent arrivals.
- Can a team keep an iteration rhythm without committing a batch?Yes, and it is frequently the best answer. Keep the fixed cadences — a regular selection conversation, a regular demonstration, a regular improvement session — because the team and everyone around it benefit from the beat, but pull items one at a time against capacity instead of agreeing a set on day one. What you lose is the shared goal a batch creates, so if the team needs one, state it explicitly for the period.
- What would you look at before proposing that a team change model?The team's own history of arrivals and changes: how many items each period were unknown when it began, how often the agreed set was rewritten, and how long urgent arrivals actually waited. If the batch survives untouched most periods, the timebox is not the problem and switching will not help. Recommend a change only when the evidence says the arrival pattern, not the ceremony, is what hurts.
saying these in an interview costs you the question
- Says flow means no planning and no commitments at all
- Claims timeboxes are outdated and flow always wins
- Chooses by team preference rather than how work arrives
- Assumes dropping the timebox removes every useful cadence
- Thinks flow removes the need to say no to requests