In previous articles I have stressed the importance of Agile Boards to good software development practice, and speculated on methodological reasons why their implementation is often half-hearted / sub-standard. Now is the time to turn to some practical advice for doing them well.

Agile Boards are two dimensional grids. The vertical chunks are (uncontroversially) called ‘columns’, and each usually represents a single step in a team’s workflow (a ‘workflow’ being the set of all the steps the work goes through from conception to finishing). An Agile Board may also have several horizontal rows, which for some reason are called ‘swimlanes’. Swimlanes are covered in a separate article, but columns are conceptually prior, and they are the topic of this article.

So, columns. Let’s start with: how many should you have?

At one level this is a ‘piece of string’ question – you need as many columns as you need, and it’s as bad to have too few as too many. But this alone is not particularly practical advice, so let’s flesh that out and see if we can give some concrete guidelines which will work in real software development environments. After all, while every context (team, time, product, programme, organisation) is somewhat different, it would be odd if there wasn’t a strong common denominator across many (or even most/all) such contexts.

The first thing to understand is that an Agile Board is a model of your real workflow, just as the map you use for navigating is a model of the real physical world. Models can be built on any scale, and by their nature they are designed to stress some details and hide others. The trick is finding the right scale and the right choice of details for your context.

Consider maps; if the challenge you face is navigating your car journey from London to Edinburgh, this particular map would not be detailed enough:

…but over-magnification is not the solution. At the other extreme you could have a 1:1 scale map of Great Britain to get you to Scotland. This would certainly show you every detail, but would not be particularly useful. You’d struggle to get it in your car, for starters.

But even maps of similar scale differ in the details they emphasize. Ordnance Survey maps, designed for walkers, show contour lines prominently, as the precise steepness of hills, valleys and mountains is extremely important in this context. Road maps show much less of this detail, as they focus on drivable roads where the steepness problem has already been successfully confronted by the civil engineers who built the roads in the first place.

How does this apply to Agile Boards? Well the Simplest Board Of All, the lowest of Lowest Common Denominators, which works for literally any kind of work, has just three columns:

While this may be suitable for some simple scenarios, and is better than ‘no board at all’, it is inadequate for professional software development. What will happen is a large number of tickets will spend a large amount of time immobile, stuck in the middle in the ‘Doing’ column, while a great number of discrete activities happen to them. These activities will often represent genuine progress towards ‘Done’, but this progress is not visible on the board due to the lack of detail. Since the fundamental objective of a Board is to show and drive progress towards ‘Done’, this board is set up to fail.

There are in fact occasions where tickets do get stuck in one column for long periods of time. On a well-designed board that fact will generally indicate some kind of problem that likely needs active management. A correct setup will highlight where there is a Stuck Ticket Problem, whereas if your board design itself ensures that multiple tickets are always Stuck, you’ve drowned the signal in the noise and your board is not doing its job.

But too much detail is also unhelpful, as here:

An outbreak of Column Fever will drown people in complexity – it is hard to scan such a board, and to keep on top of all those columns. It is rare in my experience that a single software development team needs >20 columns to adequately represent its workflow, though if you were modelling something more complex (perhaps the workflow of an entire large organisation, of which software development is but a part) this number of columns becomes far more plausible.

In general you find the sweet spot of roughly the right number of columns through a process of trial and error. The foundational principle of Kanban is ‘start with what you do now’, so just put down your current workflow into an Agile Board, monitor it, and tweak as you go. Of course, as with anything in life, the more experience you have setting these things up, the fewer rounds of tweaking you’ll need to get something really good.

In the next article we’ll do a case study, working through the application of these ideas to a hypothetical (and quite generic) software development team to come up with a board design whose columns are fit for purpose.