Scheduled Release Train Workflow
Run releases on a fixed cadence where features board the next train or wait, keeping the schedule independent of feature anxiety.
Objective
Establish a predictable release cadence where the schedule is the authority and features adjust to it, not the reverse.
Environment
- A team large enough that release timing conflicts arise
- CI capable of building a train candidate on schedule
- A visible release calendar
Steps
1. Pick the cadence from delivery data
Analyze merge-to-production lead time over recent months and choose the most frequent cadence the team sustains (weekly or biweekly).
Expected state: The chosen interval is achievable with historical throughput, not aspirational.
2. Publish the train calendar
Announce cut dates, freeze windows, and departure dates a quarter ahead, with a standing rule that missed features wait for the next train.
Expected state: Anyone can answer when does my change ship from the calendar alone.
3. Board features by cut date
Features merged and green by the cut date board automatically; anything later rolls to the next train without exception debates.
Expected state: Boarding decisions are mechanical and visible in the train manifest.
4. Run the train manifest review
Before departure, review the boarded set for coherence: incompatible half-features are held back together, and the notes draft reflects the actual cargo.
Expected state: The departing train carries a coherent, documented set.
5. Depart on time, small delays only
Ship on the scheduled date; allow slippage only for blocking defects, never for last-minute feature additions, and hold the rule visibly.
Expected state: Departure dates are met or explicitly delayed for defects, and the distinction is public.
Expected outcome
A release rhythm stakeholders can plan around, where missed features cost one known interval instead of negotiating an exception.
Verification
Departure dates over a quarter match the calendar except documented defect delays; boarding rejections are visible and require no escalation.
The schedule is the authority, the feature adjusts
Ad-hoc release dates make every ship a negotiation and every slip a political event. A fixed train inverts the authority: the date is immovable, features either board or wait, and everyone can plan around a rhythm they can see a quarter ahead.
Q4 train calendar (published Sep 30)
train cut (Fri) depart (Tue)
26.10 Oct 10 Oct 14
26.11 Oct 24 Oct 28
26.12 Nov 07 Nov 11
26.13 Nov 21 Nov 25
boarding rule: merged + green by cut -> boards
feature X merged Oct 24 18:40 -> boards 26.11
feature Y merged Oct 25 09:12 -> waits for 26.12
(no exceptions, no debates)Cadence from data, not ambition
A weekly train chosen by enthusiasm with a monthly-throughput team fails by the third cycle and discredits the model. The interval should come from historical merge-to-production data, then tighten gradually as the pipeline improves; the train must run on time above all.
Public boarding decisions kill the escalation
The expensive part of release scheduling is the exception debate: my feature is special. A visible train manifest showing exactly what boarded and what waits, governed by a mechanical rule, removes the negotiation arena entirely.