In short: Release policy decides when work reaches the floor, and the default of dropping the whole day at shift start inflates work in progress without moving throughput, which Little's 1961 result makes arithmetic rather than opinion. The structure comes from working backwards through every despatch deadline, sizing each wave against the drain rate of the slowest downstream station instead of the picking rate, and holding a buffer for short picks discovered at packing. Waveless release is a policy in its own right, governed by a work in progress cap in the CONWIP tradition, and it fits steady arrivals and put wall sortation better than it fits multi carrier despatch. The diagnostic is a cumulative curve of released against completed work by quarter hour.
At 08:05 the day's 4,200 orders are released in one block. Every picker in the building has work, which looks like the point. The packing benches stay idle for the first forty minutes because nothing has been picked yet, then take delivery of a queue that grows all morning and never clears. The 16:30 trailer is held for thirty five minutes, the shift runs long, and the daily report shows every order despatched, so nothing gets changed.
The release decision is the one lever in the building that costs nothing to pull. It does not need capital, headcount or a layout change, and in most operations it has never been set deliberately. What exists is a WMS default and a habit.
What a wave actually commits you to
A wave is a set of orders released together with a completion deadline attached. The moment it goes to the floor, three things are fixed: the work is now in progress and hard to reprioritise, the downstream stations inherit its shape, and whatever inventory it consumes at the pick face is committed.
That last point catches people. An order sitting unreleased can be re-planned, cancelled cheaply, or merged with the next line the customer adds. An order that has been released is allocated, printed, and often already in a tote, and unwinding it costs a touch that nobody planned. Releasing early converts flexibility into work in progress at a fixed exchange rate.
The reason waves exist at all is sortation. Grouping orders so they can be picked together and separated afterwards is what makes multi order picking possible, which is a much larger saving than any routing change, and AH1 covers where that trade sits. Wave planning is the layer above that decision: how many of those groups go out at once, and when.
Work backwards from every despatch deadline
Most sites can name their cut-off. Very few have written down the full set, and the full set is what the release plan has to satisfy.
Take a realistic despatch profile. A regional parcel trailer at 13:00, a national parcel trailer at 16:30, and a pallet network collection at 19:00. Each has a loading window, and loading cannot start until packing has produced enough volume to make it worth opening a door.
Work the 16:30 departure backwards. The vehicle needs to be loaded and sealed by 16:20, and loading 900 cartons at that door takes about 35 minutes, so packing has to be finished by 15:45. Packing 1,400 orders at twelve stations running 38 orders an hour is 456 an hour, so a little over three hours, which puts the pack start at 12:40. Picking has to be far enough ahead of that to keep the benches fed rather than merely finished by then, so the wave releases at around 11:15 with the pick complete by 15:00.
Then add the buffer that gets forgotten. If six percent of order lines short pick and need a chase, that is 84 orders coming back round, and the second pass has to complete before the pack deadline rather than after it. Twenty five minutes of protection in the chain is cheap; discovering the shortage at 15:50 is not.
Do that for each departure and the release times fall out. It is the same backward scheduling logic a planner already runs against a production line, applied to a despatch schedule, and the output is a small table of release times that can be published to the floor.
Releasing everything at once buys nothing
Little's Law, proved by John Little in Operations Research in 1961, says the average number of items in a system equals the arrival rate multiplied by the average time each spends there. Applied to a picking operation: work in progress equals throughput multiplied by cycle time.
Throughput is set by whichever resource is slowest, which in most manual buildings is packing rather than picking. Once that resource is saturated, adding more released orders cannot raise throughput, so the extra work in progress shows up entirely as longer cycle time. Hopp and Spearman make the same point in Factory Physics (2008) about job shops, and a warehouse behaves the same way because it is the same queueing structure with different vocabulary.
What that longer cycle time costs is concrete. Order changes and cancellations that arrive during the day hit orders already picked, so they cost a return to stock rather than a keystroke. Any problem discovered in a wave affects a much larger pool of committed work. And the operation loses its own visibility: when everything is in progress, nothing is late until suddenly all of it is, because there is no queue position to read.
The counter argument from the floor is that pickers should never wait for work, and it is a fair one. The answer is a release buffer sized in minutes rather than in days. Enough released work that no picker stands idle, which for most operations is somewhere between thirty and ninety minutes of picking, and nothing beyond it.
Waveless release is still a release policy
Continuous release is often described as the absence of waves, which under-sells it. Work is released one order or one task at a time as capacity frees up, against a cap on how much may be in progress at once.
The mechanism has a name outside warehousing. Spearman, Woodruff and Hopp described CONWIP in the International Journal of Production Research in 1990: hold total work in progress constant, and let completion of one job authorise release of the next. Land and Gaalman's work on workload control in the International Journal of Production Economics in 1996 covers the same ground from the job shop side, including the failure mode where a release rule that looks smooth in aggregate still starves specific resources.
Waveless fits well where order arrivals are steady through the day, where sortation happens at a put wall that can be loaded continuously, and where despatch is a single carrier with a late cut-off. It fits badly where a sorter needs a full batch to run efficiently, where store orders must be picked in route sequence for a fixed vehicle, and where several carriers pull work in different directions at different times.
Plenty of buildings should run both: waveless for the parcel stream and waves for pallet despatch, on the same floor, with a shared work in progress cap so the two do not compete for the same pickers unnoticed. Van Gils and colleagues reviewed how batching, zoning, routing and workforce decisions interact in the European Journal of Operational Research in 2018, and the consistent finding is that these choices are not separable, so a release policy chosen without reference to the sortation design will disappoint.
Size the wave against the slowest downstream station
The common sizing error is to set wave size by picking capacity. Picking is rarely the constraint, and a wave sized to keep pickers busy will bury whatever comes next.
Compute the drain rate of each downstream stage: packing at stations times rate, sortation at the sorter's rated throughput derated for jams and induction gaps, despatch at cartons loaded per door hour. The lowest of those is the wave size per hour that the building can actually absorb. A wave that puts 1,200 orders into a pack area with a 456 an hour drain rate has created two and a half hours of queue on release, and the tail of that queue is what makes the trailer wait.
The failure this produces has a shape worth recognising. Every trailer leaves on time, the daily despatch report is clean, and the operation runs forty hours of unplanned overtime a week that get attributed to volume. The last wave of the day is the one to inspect: released at 15:00 because the picking capacity was there, completed at 18:40 against a shift that ends at 18:00, and the cost of that decision sits in the payroll extract rather than in the despatch report.
The arrival profile limits how much smoothing is available
A release plan can only smooth work that has arrived. If sixty percent of the day's e-commerce orders land between 14:00 and the 17:00 cut-off, no release rule creates morning work out of them.
Build the arrival curve from a quarter of order header timestamps, by day of week, and compare it against the despatch deadlines. What that comparison shows is how much of the day is genuinely plannable and how much is a fixed sprint. The plannable part is where wave structure earns its keep. The sprint is a capacity question, and the honest options are a longer despatch window, an earlier cut-off, or more people in the last three hours, with the hours side of that belonging to the labour plan (Y2).
The comparison also tells you whether your cut-off is set where you think. A published 17:00 cut-off that in practice requires orders by 16:20 to make the trailer is a promise the operation is quietly failing, and it shows up as a small persistent tail of same-day orders that despatch the following morning.
Release replenishment ahead of the wave that consumes it
A wave that empties a pick location halfway through is the most expensive kind. The picker records a short, the order goes to a chase queue, the chase happens after replenishment lands, and one line that should have taken forty seconds consumes several minutes across three people.
The fix is to plan replenishment against the wave rather than against a min-max trigger. Before release, sum the demand each pick location will see from the orders in the wave, compare against the quantity currently in that location, and generate replenishment tasks for every location that will not survive the wave. Release those tasks first, with enough lead to complete before the pickers arrive.
This costs almost nothing to build because both inputs already exist: allocated demand by location from the wave, and on-hand by location from the WMS. The output changes replenishment from a reaction into a scheduled precursor, and it removes a category of short picks entirely rather than making the chase faster.
Where this stops
Release policy redistributes work in time. It does not create capacity, and in a building where daily demand genuinely exceeds throughput, a better wave structure decides which customers are disappointed rather than whether any are. FF6 covers the capacity question properly; the signal that you are in that situation is a release plan that has no feasible solution regardless of how the waves are cut.
Two smaller limits are worth stating. Wave arithmetic runs on assumed rates, and the rates move with mix: a day heavy in multi line orders packs slower per order than the average that sized the wave, so a plan built on a single blended figure will be wrong on exactly the days that matter. Rates by order profile rather than one number for the building is the correction, and it needs a few months of station level data to be stable.
And the smoothest theoretical release plan can be socially unworkable. Teams organise around the rhythm of the day, breaks are scheduled, and a plan that requires the pack area to run flat from 07:00 to 19:00 with no variation ignores that people take lunch in a window. Build the break profile into the drain rates before you compare them against anything, otherwise the plan looks feasible and the floor knows it is not.
Take one ordinary day of WMS records and plot two cumulative curves by quarter hour, orders released and orders packed; the vertical distance between them is your work in progress and the horizontal distance is your cycle time, and both will be larger than anyone in the building expects.