Dual-track agile: splitting feature discovery and delivery

Being a PM is not a piece of cake. You probably know that by now. You have probably also encountered a long list of features hanging in the air, unsure why half of these features were on that list in the first place. This is exactly why brief discovery projects are important in figuring out whether it’s worth developing a feature before going into the details of how to develop it at all.

Dual-Track Agile 

If you have ever considered doing discovery before developing a feature, you might have also heard about dual-track scrum. It is an agile approach whereby discovery and delivery in the product management process are split into 2 parallel tracks. Discovery is about validating an idea, determining whether it makes sense to do at all. Delivery is about determining in detail how to build it and then actually building and releasing it. The discovery to delivery process is continuously iterated throughout the product lifecycle and in this way. Both tracks, discovery and delivery, happens concurrently, with a great deal of cross-team collaboration.

The primary reason to separate the efforts of discovery and delivery is to make sure you’re not wasting more time than necessary on features that should not be built anyway. The benefits of dual-track agile are speed and an improvement in the quality of product development work.

Discovery is typically done by a discovery team, with three distinct roles. The PM determines whether a feature can be valuable to a customer/stakeholder, the designer determines whether it can be made usable, and the developer determines whether it is technically feasible to build and also provide estimates for how long it would take to build. One way to find the version of a feature that is valuable, is to do a user story mapping. Another approach that is often used by designers is the Double Diamond, where extra effort is put into making sure the right problem is being solved.

Delivery is done by the delivery team, and can be split into two phases. In grooming, the feature is fleshed out in more details. The final set of user stories and requirements to be fulfilled and the exact specifications and designs are determined. In development, the feature goes into a sprint and is coded and then released.

The product manager and/ or product owner oversees and facilitating the flow of work for both tracks.

Why it makes sense to split discovery and delivery

Usually after the discovery phase, a feature goes back to the roadmap, this time with less uncertainty attached to is. Doing it like this, with two steps is the essence of Dual-Track Scrum. Separating out Discovery ensures that only features that make sense to do, i.e. that are valuable, usable, and feasible, go into Delivery.

In other words, the goal is to achieve maximum outcome with minimum output. Outcome refers to the effect of the solution or the value you’re trying to deliver to the client’s issue, and output refers to the amount of new functionality that is built.

Key here is to deliver value, outcome, building the least possible amount of functionality output. Why release a software with a thousand features to solve an issue, if the same could be achieved with a hundred well-designed features? Less is more here. Dual-Track Scrum gives the teams more focus, reduces their rework and improves the ability to plan, while maintaining agility.

Separating Discovery of a feature from the process of detailing out its requirements and specifications can be very useful. However, it’s crucial to keep a balance and make sure that these two are not too separated. This could lead to information and insights being lost, which risks efforts being wasted.

Some risks of splitting discovery and delivery

If the discovery team and the delivery team consists of different people, or if there are several weeks (or even months) between the phases, then the insights from Discovery risk not being caught. A bad handover can lead to three main problems.

First, late-stage changes in the way of implementing the feature risk not solving the original problem the customers/stakeholders had in mind, if the underlying feedback that triggered looking at the problem in the first place is not handed over into Delivery properly.

Second, there is also the flip-side to the issue above. The development team may believe a certain aspect of the issue is crucial to solve, and put lots of effort into solving it only to find out later that it was actually not that important. This results in wasted time and effort.

Third, to avoid the two problems above, if the handover has not been done properly, the PM and the developers may have to spend time going back and forth in further meetings to clarify things, potentially involving stakeholders in more discussions.

Keeping the connection in dual-track agile

A good way of keeping the connection is to work with Opportunity Solution Trees, where there is a direct link between the problems being solved (the Opportunities), and the features to build (the Solutions).

Another good way to make sure the connection between discovery and refinement is not lost is to write a product requirements document (PRD) based on a template and let it live across the two phases. When the feature Discovery is recorded in a document, it can be directly handed over into Delivery.

If done properly, this means that the relevant notes from Discovery, including why the problem is being solved in the first place, are handed over – which goes a long way towards resolving all three of the above mentioned problems.

A good document can also help avoid the following problem. If the development team is not properly involved in Discovery, there is a risk that it turns out that the way the feature was envisioned during Discovery is not feasible.

If this is found out during a sprint, then that results in a disruptive postponing of doing the feature, which leads to wasted time. With the Discovery recorded in a document that is handed over to Delivery it is more likely that your team will find this problem earlier.

Using an outliner to write the PRD makes it easier to bridge this two-step process, as (together with a good template) it becomes possible to add the all relevant details without getting overwhelmed and have them stay relevant across the handover between Discovery and Delivery.

To conclude, splitting Discovery and Delivery can be very useful to save time, resources and hassle for your team if you are an aspiring to be a great PM. However, the magic works only if the splitting is done right, otherwise it might backfire and complicate the situation.