Dual-track agile

The model came out of agile user-centred design work in the mid-2000s, when teams trying to fit research and design into sprints found that neither timeboxing them nor doing them up front worked. It has since been popularised under several names — dual-track scrum, dual-track agile, continuous discovery — and the naming variation matters less than one structural claim: discovery is not a stage that precedes delivery, it is an activity that never stops.

Three things are being asserted at once, and skipping any of them breaks it:

• One team. The same people are accountable for both tracks. Splitting them into a discovery group and a delivery group reintroduces the handoff the model exists to remove.
• Continuous, not sequential. Both tracks run at the same time on different items. Discovery is working on what comes next while delivery builds what was decided last.
• Bidirectional. Delivery learns things that change discovery's picture. If information only travels downhill, the arrangement is a waterfall with a shorter cycle.

The tracks are only meaningfully separate if each has an output the other depends on. Discovery's is not a design, a document, or a set of tickets. It is a validated item: something with evidence attached.

The fourth line on the left is the one most often missing and the cheapest to add. Recording what was ruled out is what prevents the same option being re-proposed every quarter by someone who was not in the room, and it is the part of discovery with the longest useful life.

Entry criteria are the real interface

If anything can enter delivery, discovery is decorative. A workable bar: the problem is stated as an outcome rather than a feature, at least one solution has been in front of a real user, an engineer has said out loud that it is buildable, and the smallest useful version has been identified. None of this needs to be heavy — four bullets on a ticket is enough — but it needs to be a bar rather than an aspiration.

The usual core is three people — product manager, product designer, and an engineer — frequently called the product trio. The first two are uncontroversial. The engineer is the one most often omitted, and it is the omission that costs the most.

Three reasons the engineer belongs there. Feasibility problems found in discovery are cheap and the same problems found in delivery are not. Engineers routinely propose approaches the other two would not have thought of, because they know what is nearly free given what already exists. And an engineer who was in the room when a decision was made builds the thing differently from one who received it as a ticket.

On capacity: discovery is mostly product and design work. Engineering involvement is commonly cited at somewhere around ten to twenty percent of time, though that varies widely with domain and with how much genuine uncertainty a team is carrying. The number matters less than the shape — one engineer participating meaningfully, rotating so the knowledge spreads, rather than the whole team attending research sessions.

Discovery generally suits a flow model better than a fixed sprint, because you cannot timebox learning to a fortnight. Delivery can stay on whatever cadence it already uses. Forcing both onto the same ceremony is a common early mistake and usually ends with discovery being reported as if it were delivery, in story points.

Dual-track has an unusual property: the failed version looks almost identical to the working version on a board. Both have two lanes. The difference is in how far ahead the upper lane runs and whether anything travels back up.

• The sprint-ahead handoffDesign works in sprint N-1 and hands finished specifications to engineering for sprint N. Every sprint. This is the dominant failure mode, it is stable, and teams run it for years while describing themselves as dual-track. The tell is that engineering's input never changes a design.
• The separate discovery teamA discovery group feeds items to a delivery group. Now there is a handoff with an organisational boundary through the middle of it, which is worse than the handoff that existed before.
• The enormous bufferDiscovery gets far ahead and accumulates a queue of validated designs. They go stale, the market moves, and the work of validating them is partly wasted. A buffer of a week or two is healthy; a quarter of finished designs is inventory.
• Discovery as theatreResearch happens, gets presented, and never kills anything. If no idea has been abandoned on evidence in six months, the track is producing reassurance rather than decisions.
• Delivery pressure eats itUnder a deadline, discovery is the first thing cut, because its cost is immediate and its absence is invisible for months. Then it never comes back, because by the time the consequences arrive nobody connects them.
• No exit criteriaDiscovery with no definition of enough runs indefinitely on the most interesting problem rather than the most important one.

A useful diagnostic, asked of a team that believes it is running dual-track: name the last thing discovery killed, and name the last time something learned during a build changed what discovery was working on. Two blanks means two lanes on a board and one waterfall underneath.

Delivery is easy to measure and discovery is not, which creates a predictable pressure: discovery gets measured with delivery's instruments, reported in story points, and judged on how many artifacts it produced. That rewards exactly the theatre described above.

• Assumptions tested per cycle — the closest thing to a throughput measure that does not incentivise producing documents.
• Time from question to evidence — the cycle time of learning. Teams that can answer a question in three days behave very differently from teams that need six weeks.
• Proportion of ideas killed — a discovery track that validates everything it examines is not testing, it is confirming.
• Staleness of the validated buffer — how long items sit between validation and build. Rising staleness is the early warning for the buffer trap.

The measure that actually matters belongs to neither track: the share of shipped items that moved the outcome they were justified by. It is the only number that tells you whether the whole arrangement is doing its job, and it is uncomfortable enough that most organisations do not compute it.

Dual-track is a response to uncertainty about what to build. Where that uncertainty is genuinely low, running it produces ceremony and no information — and doing so teaches the organisation that the practice is overhead, which makes it harder to introduce where it would have helped.

• Compliance and regulatory work. The requirement is written down by someone outside your organisation. There is nothing to discover about whether it is wanted.
• Contractual fixed scope. Discovery that cannot change what gets built is not discovery.
• Migrations and replatforming. The target is known. The uncertainty is technical, so what you want is spikes and prototypes, not user research.
• Very small teams. Three or four people sustaining two tracks usually means neither is done properly. Better to alternate deliberately and honestly than to claim a parallel structure that does not exist.
• Well-understood internal platform work. Your users are down the corridor and the requirements are legible. Talk to them; you do not need a track.

If you are starting

1. Put an engineer in the room first. Before any process change, before any board redesign. It is the cheapest intervention and the one that changes the most.
2. Set an entry bar for delivery — four bullets, not a template. Enforce it once, visibly, on something that does not clear it.
3. Cap the buffer. Two or three validated items ahead. When it exceeds that, discovery moves to the next risky assumption rather than designing more.
4. Make the killing visible. Report what was abandoned alongside what was validated, in the same forum, with the same weight.
5. Protect a fixed slice of capacity and defend it during the first deadline, because that first deadline is where the practice is actually decided.