Betteridge would say “no”. I would say “maybe”. However you feel about swimlanes, I believe they can be used for good in spite of the Prioritisation Problem.
Any headline that ends in a question mark can be answered by the word no.
— Betteridge’s law of headlines
With that out of the way, let’s first agree what Swimlanes are and what the Prioritisation Problem is:
- Swimlanes are when your board (Sprint or Kanban) has horizontal rows representing multiple workstreams
- The Prioritisation Problem is when your priorities effectively determine which items get done and which do not
For example, you may have swimlanes that separate bugs, design work, infrastructure, etc. which keeps the flow of different functions apart. Alternatively (and more insidiously) you may have swimlanes for each “priority”.
Avoiding the Prioritisation Problem
Assuming you have a cross-functional team of (mostly) cross-functional people, there is only one logical way to avoid the prioritisation problem when using swimlanes: don’t.
Don’t split your swimlanes by function, “priority”, or component. Don’t confuse people by putting some things visually above others on the board when there is no meaningful hierarchy in reality (“Why is Infrastructure at the bottom?” or “Why isn’t API at the top?”).
And most importantly, don’t let swimlanes determine which items get done and which do not get done.
Simple Swimlanes for Cross-Functional Teams
If we are to avoid the prioritisation problem but still take advantage of swimlanes, here’s what I recommend: have but two.
Keep it as simple as the following:
- Blockers & Bugs includes items where Priority is Blocker (of which there should be only a handful a year and you want people to get on them right bloody now regardless of what else is going on) as well as Bugs, otherwise known as remedial work.
- Everything Else includes, you guessed it, everything else! If it’s not a blocker or a bug then it goes here, in the order recommended by Product. If your TODO column allows 10 items, at least 8 of them should be in this swimlane.
It’s the job of the Product Manager to ensure a smooth trickle of non-project-related bugs on the board in a meaningful order so there are always items being fixed but you don’t spend all your time extinguishing fires.
Ok, but why?
The simple answer is that it doesn’t mislead people into a false sense of prioritisation when we’re already putting things in TODO in the order we want them done.
It also has the advantage of being simple as chips and when it comes to process I’ll always prefer the light-touch option if the result is the same.
What about functional teams/people?
With a cross-functional team of functional people (team does many things, each person does one or two things) swimlanes would be mostly redundant because there’d be a limited number of items any one person is capable of doing anyway.
With a functional team of functional people, swimlanes are completely redundant because, by definition, everyone is capable of doing everything on the board.
What about components/codebases?
Perhaps your product has several moving parts — a front-end, back-end, API, infrastructure, etc. Perhaps you’d like this modelled on your board. You could create a swimlane for each component, but what would it actually achieve?
Unless you’ve got dozens of items in each column it’s not going to add much clarity but it will add a lot of noise.
And the politics of why one person’s pet component is below someone else’s just isn’t worth the hassle.
Conclusion
Keep it simple. As simple as possible. Less is more, costs less, does more, more or less.