In previous articles I have discussed the theory and the practice of choosing vertical columns for an Agile Board to represent the workflow steps that tickets pass through as they move across the board from left-to-right. But a board is a two-dimensional grid, and we now turn to the other, vertical plane. For some reason, rather than the conventional terminology of columns and rows, the jargon in Agile Board World is to talk of columns and swimlanes, so that is our topic here.

Previous articles have argued that using the vertical plane to show priority is a better method than using priority flags, and that one-ticket-wide columns on an Agile Board implement this beneficial principle. You can move a ticket up to show an increase in priority, but other other tickets have to move down to make room – your board is both showing and enforcing a trade-off decision:

This example shows tickets moving within a single swimlane. But what if you have multiple swimlanes, stacked vertically one on top of the other? In this case you must stick by the rule that vertical position is always and only used to show priority, and that means we must set up our boards such that higher swimlanes have a greater priority than lower ones. This restricts the meaning we can give to swimlanes on a board.

Let’s consider the hypothetical board below, which has 14 tickets on it, distributed across three swimlanes. I have used the triangulation method to show the order of tickets. Whatever meanings we give to the red, yellow and green swimlanes, it must be the case that ticket 4 is more important than ticket 5, and ticket 11 is more important than 12.

Very often you will find Agile Boards are set up with swimlanes corresponding to functional areas, and this may conflict with the principle that vertical position shows priority. If it does conflict, you should not use your swimlanes to show functional areas (there are other means of filtering down to the functional level, which I will cover in a future article).

I recently spent some time in a team building an enterprise level identity system, and three of our functional areas were 1) registration, 2) sign-out and 3) user uplift. As it turns out, there was not a clean and strict mapping of priorities onto these functional areas; some registration work was relatively important, and some was not, and the same applied to the other two functional areas. We therefore did not set up a swimlane for each functional area, as the board would have been falsely indicating the priority of some tickets.

So what should you map your swimlanes to, so that you don’t break the vertical position shows priority principle? There are no doubt many possible answers, but I will consider two swimlane patterns below that between them cover a large percentage of cases.

First let’s consider a team that is in control of its own delivery cadence, and either is already doing, or aspires to move in the direction of, Continuous Delivery; in other words, they release work to Live in frequent small batches. What swimlanes might be chosen by such a team?

This team’s board needs to cope with both normal, planned work, and the all-too-common situation that something super-urgent crops up, requiring normal planned work be dropped immediately until the crisis is over. Such emergency situations are typically due to the discovery of a nasty bug in Production.

Since Emergencies are the highest of all possible priorities, they go in the highest lane up the board, with ‘normal work’ sitting below it, as here:

How do these swimlanes get used in practice? We of course want visual representation of work and preferred team behaviour to dovetail neatly and reinforce each other, and this swimlane layout can certainly do so.

Team rules around emergencies are usually something like: 1) verify any claim that new work really deserves ‘emergency’ status, 2) if it does, everybody who can help with the emergency does so immediately and only returns to other tasks when they can do no more on the emergency work.

A top-of-the-board Emergency Lane is admirably suited to this. Any ticket in that lane is above the fold on a computer screen, and is the very first thing any user’s eyes fall on. A new ticket arriving in this lane cannot be missed, and is a clear signal for the appropriate group of people to verify if the ticket is a genuine emergency or not, in which case they move the ticket out of the top lane. For tickets that stay in the Emergency Lane, that is again a strong visual signal that work exists that needs full and immediate attention, with team members resuming other work lower down the board only when the emergency allows.

The disruption caused by emergency tickets is considerable, even worse than normal context switching, since a) there is usually no option to get the prior work to a nice, neat point before dropping it, and b) working on an emergency often leaves you in a frazzled mental and emotional state, not easy to switch back out of. This makes it critically important to ensure the Emergency Lane is treated with proper respect, ie for genuine emergencies only. Such disruption is only merited in extreme cases.

There can be a temptation for people to try to slip tickets into the Emergency Lane just to get stuff done faster, and the team need to be on their guard against any freeloading on this crisis-management process. The very term “Emergency Lane” is helpful; less impactful alternative names such as “Expedite” don’t provoke such an emotional response. Saying you want to “expedite” a ticket is really quite different from looking a colleague in the eye and declaring that your work is a genuine emergency!

This two lane pattern of Emergency Lane and Normal Prio Lane works, without much modification, for the majority of modern software development teams. It also applies to most teams outside the world of software – I have successfully run a marketing and a finance team using this pattern of Agile Board, for example.

However I use a different board pattern in situations where releasing continually is impossible, meaning you cannot avoid having less frequent, big-batch releases, which can be seen queueing one after the other a considerable time in advance. A canonical example would be an iOS team, where the release process has a major bottleneck that cannot be overcome; namely, the submission and approval process of the App Store, which takes around a week, during which time you can make no further changes to the submitted binary without the clock starting again.

Typically iOS teams respond to this constraint by aiming for one or two releases to the App Store a month, and it would be quite normal to have company personnel actively working across perhaps the next three iOS releases. This would be reflected in the structure of swimlanes on the iOS team Agile Board:

This hypothetical team has version 1.2.1 already out in the App Store, and the main focus of team is currently on the next release, v1.3. As the end of this release approaches, team members who are freed up will gradually shift on to the following release, v1.4. Naturally this is of lower priority (as reflected by the lower position of its swimlane), and if anything comes up in v1.3 people will switch back to that. The position of the swimlanes helps team members make the right decisions – it’s more important to get the v1.3 binary completely finished and into the App Store queue this week than to work on some functionality in v1.4 that isn’t shipping till next month.

And this pattern repeats. Perhaps the planned release after v1.4 is a major new version, v2.0. Some people (perhaps Product, Architects, Designers…) are already starting to put some preliminary work into that one, and that can be neatly shown on the board. But if they were needed to work on v1.3 or v1.4, you would generally expect them to interrupt work on v2.0 to do so, and the board shows that visually – those lanes are higher up, so that work is higher priority. You can use the triangulation method and trust what it tells you.

In summary, these are two practical swimlane patterns that together cover the needs of many teams;  one for small-batch release setups where the version number of your tech product changes frequently, and it is hard to predict ahead of time exactly which version a given piece of work will end up in. The other is for large-batch release setups, where these things are much more likely to be known up front. In both cases the swimlanes respect the rule of using vertical position to show priority, and all the advantages of being able to easily read the board by triangulation are retained.

It is of course always possible that any given team may empirically discover alternative swimlane arrangements that work for them, but to abandon the use of the the vertical plane to show priority is usually a retrograde step, and should be avoided, as with the examples given here.