What is Dual-Track Agile?
The term Dual-Track has become very popular very recently due to a) everyone wanting to build more discovery into their process; and b) a certain Marty Cagan book that needs no further introduction.
For those of you that are visual learners, here is the most popular graphical representation (diagram?) of the dual track process:
Courtesy of Jeff Patton — Dual Track Development is not Duel Track
The essence of this is to create a very iterative, cheap, fast discovery process which feeds a more costly, production-ready, delivery process, which itself feeds back into the discovery process. Very lean at its core.
Definitions
As this is an article addressing some agile-like habits, where would we be without defining what an Epic is!
Epic — A piece of work directed at achieving a particular desired outcome. It’s super important to nail down the desired business and customer-based outcomes (ie. desired change in behaviour) out of the gate as Epics should be strategic in nature. That is: guided by the business strategy and being born in the world of a ‘problem to be solved’. For a lot more on this specifically, and making Epics meaningful to all that they’re impressed upon, listen to The Product Experience — Outcomes over Outputs podcast that was recently rebroadcasted.
Ideas — Potential ways to deliver a solution that moves you towards achieving the desired outcome of the epic. You want many ideas per epic and ideally, they’re based on research and are posed as a hypothesis. Ideally you’re not testing hypotheses that have been pulled out of thin air unless you’re a startup with a wildly new product, you’re clairvoyant or you have no other choice.
Stories — The corporeal body of a successful idea. More on these later.
Tasks — Fixed scope, known deliverables that are not stories. 🤓
Sub-tasks — oh yes, we’re going there, again, more later.
Bugs — essential to consider in sprint planning, not essential for me to define in the grand scheme of this article.
Project — you can of course use a project in Jira for basically whatever you want: a product, a team, a request queue or shock of all shocks, an actual project. Set them up as you need, your own process friction will no doubt inform you on the correct approach.
Board — a particular view (via a Jira filter) of tickets in columns based on status, grouped in a particular way. This one thing is what makes Jira outstanding IMHO.
One Backlog
Before we get our hands dirty with workflows, it’s important to mention something that is baked into the process detailed here: it’s focused on a single product backlog
I’ve read many of the various articles on implementing a dual-track style development process and there are a number which assume discovery is done by one team, delivery by another. If that’s the boat you’re in then aside from needing a bigger boat, not being exposed to the full glory of product development and probably having an odd Jira setup to begin with, you may or may not be able to build everything I talk about here. The examples shown assume that discovery tasks are prioritised with delivery tasks as a part of one backlog. You may be able to tease things out into two backlogs/teams, but in the long run you’ll encounter problems in other areas, for example, overall prioritisation of work (two teams with differing priorities) and high WIP in certain areas of the process.
If you’re sitting comfortably, we’ll begin…
Discovery & Delivery
First things first, and going back to the Jeff Patton illustration, we can simplify it as follows:
This is a very obvious representation, but looking closer, discovery and delivery are themselves composed of two stages and a workflow connects each part, as:
These four quadrants (please feel free to rename them) are key to building the Dual-Track development process in Jira.
Planning and Execution
To view the four quadrants another way, they can conceivably be shown as two columns as:
Again a very simple view, but you see that central, dividing line between planning and execution? That’s where the magic happens. That’s where the Jira boards really show their worth.
As Jira boards all revolves around the status of the various tickets flowing through them, let’s overlay some status categories — I’ve grouped a bunch of individual status values for clarity:
The range of categories shown here may perhaps raise some questions in terms of usefulness. We know that successful software is about more than just raw development — yes, good definition and design lead a path to better results. My point is that the workflow behind each ticket type should reflect this and be a complete collection of transitions that represent the full continuum of its (actual) life. If you’re used to a Jira workflow that revolves solely around To do > In Development > In QA > Deployed, you’re only seeing half the picture, literally.
As an aside, I’ve left off one potentially useful column after Deployment, ‘Monitoring,’ but by all means add it at the end as it’s a very good habit to get into.
To go back to the place where the magic happens: Ready For Development. This status should be held sacred. Doing so is the only thing that will keep the backlog protected and clean. It is the divide between chaos and order; the divide between noise and signal; the divide between effectiveness and giving up on ever prioritising the backlog in the long-term.
Within Jira the above workflow can be built out more fully as:
I’m sure you get the idea…
Back to Epics
Before we continue, I just want to go back to ticket types. Epics, in the way that I use them, span the strategic and tactical side of things. The rest of the ticket types don’t (so much). Bringing back the view of discovery and delivery rows, and then layering on the tickets that live in each of those rows, it looks like:
Epics are intended to hold all ideas, stories, tasks and bugs that relate to realising the value associated to them. Because Epics drive so much debate, argument and basic condescension, it’s probable that people are forced to use them as a ‘big story’ and so the poor Epic is stuck solely in the land of delivery. Not here, my friend, not here. Epics must be firmly rooted in the land of outcomes, have discrete beginnings and ends, have success criteria and have all other tickets (work) cascade off it.
Please for all that’s good in the world, please do not create long-lived Epics called, for example, ‘maintenance’ or ‘marketing’ or ‘security’. It makes me sad, and really is a bit lazy — think hard about outcomes, you’ll be happier for it.
Just going by your own experience and also looking at how things fall in the various quadrants of activity, the development team is busy because it has the most ticket types and the most status transitions. Worse they likely have the least amount of time get things done too. It’s a good job we did lots of design iterations as a part of discovery rather than as part of delivery… 🙈
Putting it all together
The Planning Board
I use two very deliberate Jira boards to manage the main body of work — sometimes specific research efforts do fall outside of this process. The first board is the planning board. This is set up as kanban board and is used to captures all new tickets coming into the team. It has a specific column for assessing and preparing tickets as the next step, and ends with the Ready (for Development) column. The planning board takes that first column and includes Discovery and Delivery activities. I set up a couple of quick filters in order to show just discovery and delivery ticket types for the appropriate Jira projects.
The Planning Board setup which is used for all ticket types
In this example, I do have a few more status values that I’ve talked about so far, and for various reasons. New for Triage is used for a workflow specific to bugs; In progress is for Epics.
The ‘Assess / Prepare’ column is where Epics are broken down to Ideas (and Ideas then properly documented) and where Stories and Tasks are groomed — two very different activities. I also separate grooming and estimation specifically, as I’ve been in far too many of those hour-long meetings where you try and do both and only get through two tickets. More on meetings in a bit…
The absolute golden rule to using the planning board is DO NOT transition anything to ‘Ready For Development’ if it is not immediately ready to be picked up by a developer. Just don’t. Ever. Being strict and rigorous here pays large dividends and your development team will love you for it.
The Execution Board
For my team, the execution (development) phase is done in sprints. This is because we value such things as reflection, training days, not working on a constant stream of never-ending feature requests and the ability to spike code without the expectation of delivery hanging over us at the same time. It’s akin to not trying to look back and converse while you’re simultaneously running forwards.
In Jira, the execution board configuration looks like this:
As it’s a scrum board there are two main views: backlog and active sprint(s). Those I won’t show as I shamelessly use Super Mario World icons and it will likely violate many copyrights. 😬
The big thing to note is that the process on the Execution board begins with Ready For Development, even though there are ticket transitions that can, and have happened before this status. Very important, and to reiterate the value of boards in Jira, they can be configured to just show one specific view of the full picture. Doing this ensures that no ticket will ever appear on the board (predominantly used for development) if it’s not classed as Ready. Keep that backlog pure! You can thank me for this practice later when you’re toasted in your local drinking halls. 🍻
If you need more information on the basics of setting up boards, have a look at Atlassian’s documentation on Jira boards
A note on sub-tasks
And you thought I’d forgotten…
One aspect of active sprints that we’re having a great time with is sub-tasks. We often organise the board by stories because that’s generally where the value to our customers lies. Using that view, we can immediately see what needs to be done in order to get that specific piece of value out into the world.
But why sub-tasks? Because of our process.
We approach it as:
-
Groom the stories and tasks as a team, led by the product manager. The premise and design should be known due to the discovery track, so no surprise here!
-
The stories are broken down by the development team, based on architectural approach, into sub-tasks. Tasks that span multiple stories are highlighted and are created a sub-task linked to other stories where it’s a dependency or are promoted to a top-line task where they keep stories out of a sprint entirely.
-
Using sub-tasks as a guide, the story can be estimated using…….. story points.
-
Sprint planning then becomes a procession based on estimated number of points per sprint.
Lo and behold, this actually works.
To close, please feel free to reach out to me about any part of this, I’m more than happy to give precise detail. There is also a lot in and around design and epics themselves that I’ll dive into deeper another time as I’m fairly passionate about such things. I hope this article helps you nail the Dual-Track agile development process as it’s worth the time of setting it all up.