Product discovery / Agile / Product teams
Dual-track agile: connect continuous discovery and delivery
Use dual-track agile with one shared outcome, visible discovery questions, delivery evidence, and a practical weekly workflow for a small product team.
At a glance
Dual-track agile describes discovery and delivery happening alongside each other. Discovery reduces uncertainty about what is worth building; delivery turns selected decisions into reliable software. Keep both kinds of work visible to the same team, connect them through evidence, and continue learning after release.
Dual-track agile describes two connected kinds of product work: learning what is worth building and delivering selected solutions reliably. A team can investigate the next important question while implementation and verification continue. The purpose is to make better decisions without treating research as a one-time phase before development.
Marty Cagan’s original explanation stresses collaboration between product, design, and engineering. The article now notes that he prefers the terms continuous discovery and continuous delivery because the older label drew too much attention to process. Jeff Patton likewise cautions against interpreting two tracks as separate groups handing work to each other.
The workflow below is an original example for a small team improving invitation recovery. It is a suggested working practice, not an additional rule of Scrum or a claim about a particular team’s results.
Give both kinds of work the same outcome
Start with a change the team wants to create for users. In the example, invited members should be able to join the intended workspace after an invitation expires, without needing an administrator to troubleshoot each attempt.
That outcome gives discovery and delivery a shared reference. Discovery asks where people get stuck and which recovery approach could help. Delivery implements selected behavior, verifies permissions and expiry handling, and keeps the feature operable.
| Kind of work | Example question | Useful evidence |
|---|---|---|
| Discovery | Do recipients understand why the invitation failed? | Observation of a realistic recovery attempt |
| Discovery | Who should be allowed to request another invitation? | User needs, access constraints, and an explicit product decision |
| Delivery | Does the selected recovery flow enforce those rules? | Reviewed implementation and recorded test results |
| Learning after release | Are eligible recipients completing the recovery? | A defined measure and follow-up observations |
Keep the intended outcome in a shared document. A discovery question without a connection to a decision can become open-ended research. A delivery ticket without a connection to the outcome can become work whose value nobody revisits.
Write questions that can change a decision
“Research onboarding” is too broad to guide the next few days. “Determine whether recipients understand the difference between an expired invitation and missing permission” gives the team something specific to learn.
For each active question, write the assumption, the consequence of being wrong, and a feasible way to investigate it. Choose a method that can answer that question. A technical check is useful for token behavior; observing a person is useful for comprehension. Neither method replaces the other.
| Question | Method to consider | Decision it can support |
|---|---|---|
| Is the failure message understood? | Observe intended users working through a prototype | Keep or revise the wording and next action |
| Can requesting recovery reveal private workspace information? | Review the proposed behavior with engineering and security | Change access checks or the information shown |
| Does recovery complete in the real environment? | Run controlled end-to-end checks | Fix a delivery failure before rollout |
Record the limits of the evidence. A person completing a prototype task does not prove production reliability or broad demand. A passing automated test does not prove that the workflow is understandable.
Build a repeatable learning habit
Teresa Torres’s definition of continuous discovery includes at least weekly customer contact by the team building the product, using small research activities aimed at an outcome. This is a useful reference for a sustainable habit, rather than a reason to postpone learning until a large research project is approved.
Make recruitment and preparation visible work. Identify the relevant participants, use appropriate consent and data-handling practices, and keep a short discussion guide. Ask about actual experiences and observe realistic tasks before inviting broad opinions about a proposed feature.
Rotate participation where practical so engineering, design, and product share some firsthand context. Everyone does not need to attend every conversation. They do need access to the observations and a way to challenge the interpretation.
If customer access is difficult, state the gap. Support conversations or existing behavior data can help identify questions, but an internal guess should not be relabeled as customer evidence. Choose a concrete step toward better access and record what decisions remain uncertain meanwhile.
Coordinate a week without creating two teams
The following example shows a possible rhythm. It does not prescribe fixed meetings or equal time for discovery and delivery.
| Moment | Discovery work | Delivery connection |
|---|---|---|
| Start of week | Select the most consequential recovery question | Review capacity and the behavior already being implemented |
| During the week | Observe attempts and test the proposed explanation | Bring findings to the people writing and verifying the change |
| Decision point | Choose whether to keep, revise, or stop the approach | Update scope and acceptance criteria deliberately |
| Review | Share evidence, limitations, and unresolved questions | Demonstrate selected behavior and inspect QA results |
Count discovery effort when planning capacity. If the same engineer must build the feature, investigate a security concern, and observe users, the schedule should reflect those responsibilities. Calling the investigation a separate track does not create extra people.
Keep work in progress small. A team usually learns more from completing one consequential investigation than from maintaining a long list of vaguely active research tasks. If urgent delivery work interrupts the plan, say which learning activity moves and what uncertainty the team is accepting.
Use a decision record to connect the work
The transition into implementation should preserve the reasoning. A document that says only “approved” loses the assumptions that engineers and testers need when they encounter an edge case.
Use a compact record:
| Field | Invitation-recovery example |
|---|---|
| Problem | A recipient cannot tell how to recover from an expired invitation |
| Evidence | Dated observation notes and a reviewed description of current behavior |
| Selected approach | Explain expiry and offer the allowed recovery action |
| Alternatives considered | Ask an administrator directly; request recovery from the page |
| Important constraint | The response must not reveal private membership or workspace details |
| Remaining uncertainty | Whether the chosen wording works for less experienced recipients |
| Delivery scope | Selected states, actions, exclusions, and acceptance criteria |
| Review after release | Owner, measure, observation window, and follow-up question |
Do not demand certainty before writing any implementation work. Choose a scope that fits what is known, expose the remaining risks, and decide how to verify them. Some technical investigations need code; some product questions need an experience people can actually try.
An investigation may also end with no build. If the team discovers that a proposed feature would not address the problem, document that decision and release the capacity. Ticket creation is not the measure of discovery success.
Keep learning after the release
Before rollout, decide what the team needs to observe. For the example, define which recovery attempts are eligible, what counts as completion, and how to distinguish user abandonment from a technical failure. Use the team’s analytics or research systems for those observations.
After rollout, compare the findings with the original assumption. Check whether the audience, environment, or behavior differs from the earlier investigation. A result can justify an incremental adjustment, another research question, or a decision to stop expanding the approach.
Include delivery quality in that discussion. Review defects, missing coverage, and operational issues alongside the behavior measure. A promising design still needs dependable implementation, and a dependable implementation may still fail to solve the intended problem.
Avoid turning discovery into a quota of interviews, prototypes, or ideas. Those activities are inputs. In a review, explain what the team learned, which decision changed, and what evidence would cause another change.
Keep the workflow visible in Leera
Use Leera Documents for the outcome, research notes, assumptions, and decision record. Link the relevant document from Planner issues so the people implementing a change can find its reasoning.
Track investigations and implementation work with clear issue names and descriptions. Teams can configure issue types and their workflows in project settings, or start with their existing types and a simple naming convention. This is a team-designed workflow using general planning tools, not a dedicated discovery repository or automated research feature.
Use the backlog to choose upcoming work and the board or sprints to coordinate selected commitments. Connect implementation issues to QA cases and runs for the expected behavior. Keep product research findings distinct from execution evidence so neither is presented as proof of the other.
Start with the next uncertain decision already affecting delivery. Put the question and its owner beside the related work, identify a useful source of evidence, and choose when the team will review it. A small shared learning loop is enough to begin improving the connection between discovery and delivery.
Frequently asked questions
What is dual-track agile?
It is an approach in which product discovery and delivery continue alongside each other. The team investigates needs and assumptions while also building, verifying, and maintaining selected solutions. The tracks describe different kinds of work, not a requirement to create separate teams.
Is discovery always one sprint ahead of delivery?
No. Some questions can be answered quickly; others need more investigation, and released work creates new questions. Plan discovery around the decision and uncertainty involved instead of forcing every idea through a fixed one-sprint handoff.
How does continuous discovery relate to dual-track agile?
Continuous discovery provides an ongoing learning practice within product development. Teresa Torres describes a minimum weekly customer-contact rhythm, with the building team conducting small research activities toward a product outcome. Dual-track language highlights how this learning relates to delivery.
Does every discovery idea become a delivery ticket?
No. A useful investigation can change the proposed solution, expose a missing assumption, or lead the team to stop. Record the evidence and decision, then create implementation work when the approach and its remaining risks are clear enough for the chosen scope.
Can a small team use this approach?
Yes. Start with one shared outcome, one important question, a recurring opportunity to hear from users, and a short decision record. Make discovery effort visible in the team’s capacity. The approach does not require a separate research department or a second set of delivery ceremonies.