skip to content

Why is the queue that feeds a pull system replenished on a fixed cadence rather than on demand?

level: middleimportance: nice to knowfreq 24%

answer

  1. Separate choosing what is next from starting
  2. A known time beats an unpredictable trigger
  3. The interval caps how long ideas wait
  4. Enough options to survive one interval

basics

~20 s

A fixed replenishment cadence makes refilling the queue a predictable decision point: requesters know when their item is next considered, discards happen out loud, and the team is not dragged into a prioritisation conversation every time a slot frees.

solid answer

~50 s

**Replenishment** is the act of choosing which options move into the small queue that feeds the commitment point. Running it on a **fixed cadence** — say once a week, at a known time — separates the prioritisation conversation from the moment a slot frees. The team can pull whenever it has capacity, because the queue already holds a few agreed items; requesters know exactly when the next selection happens, so nobody has to lobby continuously; and the session is a natural place to discard options that no longer matter. Replenishing on demand couples the two instead: every free slot triggers a decision, the people who can decide are not always available, and pulling stalls while the team waits. The interval also caps how long a newly arrived idea waits to be considered — a number you can quote to a requester.

go deeper

for a junior

Know that a pull system needs a small queue of agreed options to pull from, and that filling that queue is called replenishment. Selecting an item into the queue is not yet a commitment to deliver it.

for a middle

Explain the decoupling: pulling happens whenever capacity frees, while choosing happens at a known time, so neither waits for the other. Be able to say what makes an interval too long, and what makes the queue too deep.

for a senior

Expect to diagnose. Starvation, options going stale before they are pulled, and a replenishment session that has quietly turned into batch planning are the three things to spot, and each has a different fix.

for a principal

The cadence is a contract with the wider organisation: it sets the worst-case wait before a new request is even considered. Argue for an interval you can defend to requesters, and for the standing authority to discard options in that session.

## What replenishment actually decides A pull system needs something to pull from. That something is a small queue of agreed options sitting immediately in front of the commitment point. **Replenishment** is the act of choosing which candidates go into that queue — and, just as importantly, which ones are taken out of the wider pile and dropped. Replenishment is not commitment. Items placed in the queue are still options: they can be reordered or removed right up to the moment somebody pulls one across the commitment point. That distinction is what keeps replenishment cheap. If selecting an item into the queue were itself a promise, replenishment would simply be batch planning under a different name. ## Cadence versus on demand There are two ways to run it. **On demand.** Whenever a slot frees and the queue is empty, somebody decides what goes in. It is simple, and it looks maximally responsive. **On a fixed cadence.** At a known time — weekly, fortnightly, whatever fits — the people who can decide meet briefly, top the queue up, and discard what no longer matters. Between those times the team pulls freely from what is already there. | | On demand | Fixed cadence | |---|---|---| | When the decision happens | at an unpredictable moment | at a time everyone knows | | Who must be available | the deciders, immediately | the deciders, at one known time | | Effect on pulling | can stall while a decision is made | never stalls while the queue holds items | | Requester experience | continuous lobbying pays off | there is a next date to aim at | | Where discards happen | rarely, because there is no forum | naturally, every interval | The cadence buys **decoupling**. The team's capacity signal and the organisation's prioritisation conversation now run on separate clocks, and neither waits for the other. It also converts an ambient pressure — everybody lobbying all the time — into a bounded event with a known audience. ## Choosing the interval Four things set it: 1. **How fast the queue drains.** The interval must be short enough that the queue is not empty before the next replenishment. 2. **How quickly options go stale.** If a fortnight-old selection is usually wrong by the time it is pulled, the queue is too deep or the interval too long. 3. **Who has to be in the room.** A cadence that needs somebody available only fortnightly is a fortnightly cadence, whatever the calendar says. 4. **How long a new arrival may reasonably wait.** The interval is the worst case before a fresh idea is even considered. Being able to state that number is far more useful to a requester than a vague assurance. ## How full to keep the queue Enough options to survive an interval of pulling, and no more. A queue holding a couple of intervals' worth of work is a buffer against starvation. A queue holding everything anyone has ever asked for is a promise register nobody dares prune, and it destroys the option value the commitment point exists to protect. How much work each *stage* may hold in progress is a separate matter with its own rules; this is only about the input buffer. ## A worked example The eleven-person team on a hotel housekeeping app pulls about 3.6 items a week and replenishes every Tuesday morning. They keep roughly 7 options in the queue: enough to cover a fast week without leaving anybody idle, few enough that the oldest is rarely more than a fortnight old. When a partner integration deadline lands on a Thursday, nothing breaks. The team keeps pulling from the existing queue, the integration work is added at the next Tuesday session and ordered to the front, and it is pulled at the following free slot. The requester waits at most five days to learn where they stand, and knew that bound in advance. ## What goes wrong - **Starvation.** The queue empties before the next session and people either idle or start work nobody selected. The interval is too long for the drain rate. - **Stale options.** Items are reworked or dropped at the moment of pulling because the world moved on while they waited. The queue is too deep. - **Cadence creeping into batching.** The session starts agreeing that everything selected will be delivered by the next one. That is a timebox with extra steps, and the option value is gone. - **A session nobody can decide in.** Without the people who hold the authority, replenishment becomes a discussion and the queue fills with compromises.

  • What is the sign that a replenishment cadence is too slow?
    The queue feeding the commitment point runs empty before the next session, so people with free capacity either idle or start work nobody selected. The opposite symptom is a queue that is always full while items in it get reworked or dropped when they are finally pulled — there the interval is fine but the queue is too deep, and options are going stale while they wait.
  • Does a replenishment session commit the team to the items it selects?
    No. Replenishment moves options into the queue in front of the commitment point; they remain options. The team commits only when an item is pulled across the line. Confusing the two turns replenishment into batch planning, and the queue becomes a list of promises the team has to defend rather than a buffer that stops pulling from starving.

saying these in an interview costs you the question

  • Confuses replenishment with committing to a batch of work
  • Says the queue should hold everything the team might ever build
  • Thinks the replenishment interval must match the delivery interval
  • Cannot say what happens when the option queue runs empty
  • Treats stale options in the queue as a requester problem