Get certified - Transform your world of work today


Dual-Track Scrum

18 December 2014

Kam Zaman

The aim of this post is to give readers a flavor of how I implemented Dual-Track Scrum in a previous workplace. There has been much hype about Dual-Track Scrum, but not much about how it has been put into practice. I hope this post gives you some idea of how the concepts can be applied in your place of work.

What is Dual-Track Scrum?

This is a framework in which a product development team is continuously discovering what their customers needs are, and validating those needs using evidence and prototypes. Once an idea or need is validated, the need is then represented in the form of user stories and added into the product backlog.

Dual-Track Scrum advocates that the product owner/manager, the lead developer, and the UX/UI person constantly spend their time in the discovery space, while the rest of the team concentrates their efforts in delivery. So, in a nutshell, there are two tracks, each with a different focus but with one aim: to build products customers will love. Sounds good in theory, but it can be hard to find the right balance in practice.

I think it's important to note that the driver for wanting to adopt Dual-Track Scrum came from the product team. This is the way they wanted to work, and I and the other delivery managers helped the product team bring this change into the company. It's also important to note that everyone, from the exec level right through to people in marketing, knew that this was how we were going to work. It was important that they understood our process and also knew where they fit into that process. This is where ScrumMasters, delivery managers, and Agile professionals, who work with teams and stakeholders, can really help.

One thing I was very skeptical about when I first read about Dual-Track Scrum was how it advocates mastery, autonomy, and purpose, if the lead developer is always in discovery. Did that mean that everyone else who sits within the delivery track just becomes a user-story consumer and has very little say in how they would perceive a feature to be developed?

What did we do?

We agreed that we wanted people from delivery to be able to rotate freely into discovery. Our tech stack was complex; we had a lot more specialists on the team than generalists, technically, so it made sense for us to rotate people in.

We decided that there would be two backlogs. The discovery backlog contained items that were hypotheses, which would need to be validated to work out whether something should then go into the delivery track to be worked on by those in delivery. The way in which we validated hypotheses included doing things like AB testing, looking at data, talking to customers directly, and story mapping. The delivery track still had its own product backlog; once hypotheses were validated, a user story or stories were created in the delivery backlog, with a link to the discovery backlog item, so that we could link stories back to their origin. It was important that we did that because, once a feature was worked on in delivery and released, we would then revisit the discovery backlog item to further validate whether we had solved the problem we had identified initially. This was very important, as just discovering a problem and pushing user stories into delivery isn't the end. We need to be constantly discovering, even on items that had started in discovery and been pushed out to delivery.

A Scrum team's main goal is to satisfy a customer's need. We found that with just our usual Scrum release cycles, the time from identifying an idea to actually releasing a fix for it would amount to a minimum of six weeks. Dual-Track Scrum gave us a different way of looking at our product development process, where we now had dedicated people in discovery. We didn't want there to be silos created throughout the development team, so one way of bringing people in discovery and delivery together was through the refinement sessions. We wanted to be able to get feedback from the delivery team when we felt that hypotheses in discovery were validated, and we didn't want to wait around for six weeks before we could get our validated hypotheses to delivery. We all agreed then that in order to get user stories properly fleshed out, we would have 30-minute refinement sessions every day, straight after the stand-up. Then from 11 a.m. on the delivery team was left alone to work on delivery.

One point to note here is that we had three of each skill set within the team, which allowed us to rotate people in from delivery to discovery. We had our usual delivery stand-up, and everyone attended that (including people in discovery). We noticed that because we validated our hypotheses and refined stories well with the team in delivery, the delivery team didn't need much input from the PO or UI/UX people. We also held discovery stand-ups and encouraged those in delivery to come hear what was being discussed.

Opinions represent those of the author and not of Scrum Alliance. The sharing of member-contributed content on this site does not imply endorsement of specific Scrum methods or practices beyond those taught by Scrum Alliance Certified Trainers and Coaches.

Article Rating

Current rating: 4.9 (8 ratings)


Anand Vyas, CSP,CSM, 12/19/2014 12:16:31 AM
Hey Kam,

This is very interesting. Thanks for sharing this.

I would believe the team must be very matured in SCRUM.

Anand VYas
Robert Day, CSM, 12/19/2014 4:43:36 AM
This is very interesting. In my company, we have been working with external developers on a project. They operate in an Agile way, and our product delivery is based on their two-week sprints.

We can only carry out testing on the deliverables once they have been delivered (obviously!), so our UAT is always one sprint behind the developers'. As the product has matured and the first phase has been rolled out to the business, we have engaged with business users to get them to do some real-world acceptance testing, and observations, ideas and some bugs have flowed back from that process. As we have gotten closer to real-world deployment, we've been holding user walkthrough sessions on the new application, and new ideas have come from those, too. I've been acting as gatekeeper, triaging those bugs, ideas and suggestions, and adding bugs that I've uncovered, and holding weekly 1-2-1s with the developer's PM to discuss issues raised and decide how those are going to be incorporated into the developers' Product Backlog.

So from reading Kam's article, it seems to me that we have managed to re-invent Dual-Track Scrum all by ourselves!

It suggest to me that a lot of the Agile methodology arises out of empirical evidence of "the best way of working"; and once one team or group starts using Scrum, it spreads out by association to other groups they come into contact with.
Kam Zaman, CSP,CSM, 12/19/2014 9:06:54 AM
Hi Anand,

I'm very glad that you found my article interesting. Yes, the team was very mature with the scrum process. Because of that, it was easier to adopt the dual-track framework. The team also helped evolve the process very much, and they helped us to get it to where it was.
Chandrasekaran Janakiraman, CSM, 12/23/2014 4:56:15 AM
Hi Kam, This is a very good approach. It adds more refinement in terms of building a product backlogs. Just curious to know, how was the work handled (User stories or tasks or some thing else..) for the discovery team? Did you also look at applying SAFe (Scaled Agile Framework) model in your scenario before going with this approach?
Kam Zaman, CSP,CSM, 12/31/2014 5:27:10 AM
Hi Chandrasekaran,

Thanks for your comments and your questions. We didn't look at applying SAFe. We thought that this approach worked for us best. This might be something I will look in to. In terms of the work that was in discovery, we used the same approach you would do in your usual scrum process, we wrote stories for our discovery, and those were tasked out too. The stories were not in the usual, as a, when I, so that; they were expressed as hypothesis, for example. "customers are churning more because we don't offer feature X". That hypothesis would then be tasked out so that we can validate this hypothesis.
Tasks may include the following.
- Customer interviews
- Tracking Data
- What are customers speaking to people in sales about
- What would the UX look like if we added this feature.
- How would adding this feature affect our Tech stack etc.

I hope this helps, but do let me know if you have any other questions.
Samuel Nadarajan, CSM, 1/6/2015 10:29:22 AM
Great Article! I actually heard a talk on Dual-Track Scrum last year and it showed promise at a company that was implementing it. However, the big hurdle was whether the company could hire more UX Designers (1 per team for 12 teams total).

By the way, did you or the team find issues in having 2 backlogs?
Kam Zaman, CSP,CSM, 1/8/2015 8:28:26 AM
Hi Samuel,

Thanks for your kind comments. We didn't have any issues with having two backlogs. Each backlog had its own focus, one being delivery and the other being discovery. Those who came in to the discovery track knew which backlog we were to work off. It did take time to adjust this way, but we found that having two backlogs helped to maintain the focus for each track.
Anubhuti Sharma, CSM, 1/16/2015 4:03:27 AM
Hi Kam,

Just curious to know if inputs in the Discovery tracks were given by the delivery team too. Were Product owner, Lead developer, and the UX/UI person the only people working on the discovery lines?
Anubhuti Sharma, CSM, 1/16/2015 6:34:42 AM
Hi Kam,

Just curious to know if inputs in the Discovery tracks were given by the delivery team too. Were Product owner, Lead developer, and the UX/UI person the only people working on the discovery lines?
Kam Zaman, CSP,CSM, 1/22/2015 4:49:12 AM
Hi Anubhuti,

Inputs were given to those in the delivery track, this is where I 30 minute refinement sessions everyday were the right forum for us to share those inputs. The UX, UI and product person were not the only people in discovery, we rotated people from delivery in to discovery and gave people the option of joining the discovery track.
Chad Gallant, CSM, 1/23/2015 9:02:49 AM
Great article! I worked under a variation of this methodology in the government sector. We had two main teams: one was requirements-focused and the other was development-focused. The formula worked fairly well, but there were some inherent risks.

Both teams worked under a Scrum framework. This was more difficult for the requirements team, as its "user stories" were to create user stories. Strange, I know, but we actually made it work. The requirements team was comprised of Product Owner, Subject Matter Expert, UI/UX designer, Business Analyst and Data Engineer. It was a perfect make-up for the work we were doing. The goal was to generate the backlog for the developers.

Once the requirements team had determined the business value, priorities and functional dependencies, we would conduct release planning with the Dev team. After release planning, the Dev team would further refine our user stories to include tech specs, architectural needs, etc.

We did not realize we there was a name for what we were doing, so I was glad to see we weren't unique in our approach.

The biggest downside to the way we were doing business was that the requirements team tended to gold-plate the features and stories, basically creating waterfall-style requirements. We got more efficient as time progressed, but we were still asking for more than we needed.

You must Login or Signup to comment.

The community welcomes feedback that is constructive and supportive, in the spirit of better understanding and implementation of Scrum.


Newsletter Sign-Up