Dual-track agile is usually explained with a diagram: a discovery track on top, a delivery track underneath, arrows feeding one into the other. Productboard's glossary entry gives the standard summary. Discovery produces, tests and validates ideas; delivery turns them into product. It traces the idea to Lynn Miller in 2005, Desirée Sy in 2007, and Marty Cagan and Jeff Patton in 2012.
The diagram is accurate, and it misleads managers in a predictable way. Two tracks look like two queues of work, and two queues look like two groups of people. The engineering manager who reads it that way ends up with a discovery group that is always in a workshop and a delivery group that feels like the back office. We think the manager's job in dual-track is to stop that split from forming, and to decide, on purpose, how much engineering capacity discovery is allowed to take.
Two kinds of work, one team
Jeff Patton's own description is clearer than most summaries of it. He credits Sy's 2007 paper on adapting usability work for agile teams, and he is candid that he dislikes the dual-track label and adopted it because Cagan had popularised it in teaching. His point is that discovery and delivery are two kinds of work and two kinds of thinking. Delivery work values predictability and quality. Discovery work values fast learning and validation. They are drawn as two tracks because the thinking differs. The people do not have to.
In his talk at UXDX he says it plainly: it is two tracks, it is not two teams. A product manager, designer and senior engineer may orchestrate discovery, and the whole team should be involved wherever possible.
Cagan's 2012 post was written against a specific failure: Scrum teams running little mini-waterfalls inside the sprint, where the product manager hands a spec to the designer, who hands mock-ups to the engineers. His answer is the product manager, designer and lead engineer working side by side to create and validate backlog items, with the prototype serving as the spec. Notice who is in that sentence. The lead engineer is in discovery. So the delivery track, by design, loses some of its strongest engineer's time every sprint.
What discovery costs, in hours
That is where the manager earns the title. Nobody else on the team is positioned to protect delivery while discovery runs. The product manager is accountable for discovery, and the engineers in it are usually enjoying it.
Patton's practical answer is a time box. In the UXDX talk he describes teams budgeting discovery participation at somewhere between half a day and two full days per sprint for the people involved, with most engineers staying on delivery while product and design lead the discovery work. The number matters less than the fact that it is a number. A time box is a decision the manager can make, write down, and hold people to.
In practice it looks like this. The team has six engineers and a two-week sprint. The tech lead sits in customer interviews on Tuesday afternoons and a design studio every other Thursday morning: roughly a day a sprint. One more engineer rotates into discovery each sprint, for whichever prototype needs real code. Everyone else is on delivery and knows it. Sprint planning begins with the discovery goals for the fortnight, then plans delivery against the capacity that remains. Patton recommends that order, and it is the reverse of what most teams do, which is to plan delivery to the full headcount and let discovery take its bite afterwards.
When discovery overruns, and it will, the manager has three honest options: shrink the discovery goal, move the delivery commitment, or hold both and let the sprint fail visibly. The dishonest option is the common one. Say nothing, let the tech lead spend four days in workshops, and look surprised at the review.
Keeping the other track visible
Patton's second remedy is visibility. Discovery work that lives in the product manager's notebook is invisible to the engineers building the current sprint, and invisible work breeds the two-team split. He describes evidence boards: hypotheses, sketches, experiment results, and what he calls deltas, the things the team validated, the things it was wrong about and the things it learned.
For a manager the useful move is to put discovery into the ceremonies the delivery track already has. Patton suggests the daily stand-up runs story by story and then spends a few minutes on the discovery hypotheses, and that the sprint review shows both the working software and the discovery evidence: what we validated, what we were wrong about. His line on the review, roughly, is worth repeating to a team that only reports successes: if you were wrong about nothing, you are either very clever or fooling yourself.
Cagan's follow-up on continuous discovery, a month after the first post, drops the idea of a discovery phase altogether. Discovery becomes an ongoing process of ideation, validation and description, feeding the delivery track continuously. He notes that this often suits Kanban better than Scrum. That is a process choice the manager owns, and the right answer depends on how much of the team's work arrives from discovery and how much from operations, support and debt.
What the manager refuses
Three refusals keep the model honest.
Refuse a discovery team. If someone proposes that the senior engineers "do discovery" and the rest "do delivery", you are back to the handoff Cagan was arguing against in 2012, with better vocabulary. Rotate people through discovery instead, and keep whoever built a prototype attached to the delivery of what they prototyped.
Refuse the assumption that everything discovered gets built. Patton is direct that discovery should substantially change and kill a lot of ideas. If every discovery item reaches the delivery backlog, discovery is a design phase with a new name, and the delivery track is now the bottleneck for a stream that never filters.
Refuse to measure the discovery engineers on tickets closed. An engineer who spent a day a sprint in interviews will show fewer points on the chart. If the chart is what you bring to their performance conversation, they will stop going, quietly, and the trio will be a duo within a quarter.
Where this sits in the standard
Deciding how discovery and delivery share a team's capacity sits in the Delivery & Execution domain of the EMA Competency Framework. The Body of Knowledge unit on designing how work flows covers the choice between sprint-based and flow-based delivery, and managing scope, risk, and dependencies covers what to do when a commitment has to move.
In EMA-I it comes up as a situation: a sprint is half gone, discovery has overrun, and you decide what gives.