Exploratory design and delivery design must be scheduled separately

What it is

Exploratory design is finding whether to build and what to build; duration is unknown and directions will be thrown away. Delivery design is writing a chosen direction into structure, states, and copy that engineering can start; there is a receiver and a date. Park both on one ticket, in one schedule slot, and exploration gets truncated by the date, or delivery slips because exploration is not done. Engineering’s “design isn’t ready” cannot tell selecting apart from specifying.

Separate schedules do not forbid one person from doing both kinds of work. They forbid measuring both in the same progress language. Exploration is done when a direction is recorded. Delivery is done when the file is buildable.

Why it happens

Exploration produces discarded alternatives plus one chosen direction; calendars cannot estimate it well. Delivery produces a file with a handoff bar; calendars can. Fold them into one “in design” slab and the date pressures two different uncertainties at once: lock a still-uncompared direction to make delivery, or leave engineering idle on an exploration with nothing to receive. Engineering cannot staff the work because the start signal was never defined.

Once split, explore tickets have no engineering receiver and need not pretend to be estimable; delivery tickets must not start with three frames still in competition. A one-iteration design lead only works when the delivery column holds a chosen direction, not exploration debris. Mixed scheduling makes “deliver ahead” ship an unfinished search.

Where it stops holding

An icon swap, a settled copy edit, a known defect has no exploration phase; splitting it into two tickets is ceremony. Pure research that will not go to engineering needs no delivery slot — do not mint an empty delivery ticket for completeness. A small change whose direction can be picked from an existing pattern in half a day can finish explore then deliver on the same calendar day, but it still leaves a “chosen” mark rather than one vague design task. Dual-track boards without a handoff bar are two columns that both say “design.”

Applying it

• Two ticket types or two columns: explore done = chosen direction plus discarded alternatives written down; deliver done = buildable. A delivery ticket does not start until the direction is recorded.
• The engineering queue accepts delivery tickets only. A file still showing three competing frames goes back to explore; it is not buildable.
• When one person does both, split the calendar blocks. Do not “try another direction” and “due this week” in the same block.
• How to check: take items about to start in engineering and point to the single direction and the record that chose it. Three schemes still side by side, or “in design” with no direction record, is mixed scheduling. Delivery tickets that keep changing direction after their date are exploration occupying a delivery slot.

Related

• Same group: R2.12.1 Delivering design one iteration ahead reduces mutual waiting · R2.12.2 Problems found in implementation must be written back into the design source · R2.12.3 When the joint review happens determines how much work is thrown away
• Nearby: R2.05 Completeness of edge-case delivery · R2.11 Identifying and paying design debt
• Search terms: separate exploration and delivery · dual-track scheduling · buildable versus exploring