Agile Board design principles – columns

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:agile-board-too-complex

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.

Scrum, Kanban, and the importance of visualisation

In a series of articles I discuss the importance of visualisation of work using an Agile Board for effective software development. I contend that while most teams attempt this to some extent, relatively few think about it much or do it particularly well. This article considers a possible reason for this state of affairs: the influence of the underlying methodologies used by such teams.

Scrum is unquestionably the dominant organisational methodology in software development today. Probably second in influence is Kanban, a system whose roots are in hardware manufacturing, and whose principal advocate in the world of software is David Anderson, author of the seminal book on the topic. What is the place of visualisation in each of these methodologies, and how does that relate to what we see in the workplace?

We’ll start with Kanban. The very word itself denotes a visual card, originally used to control inventory in a manufacturing production line:


In Anderson’s porting of Kanban into the realm of software, he states its major principles as follows:

  1. Visualize1 the workflow
  2. Limit WIP
  3. Manage Flow
  4. Make Process Policies Explicit
  5. Improve Collaboratively (using models & the scientific method)

In other words the First Commandment Of Kanban, just as the meaning of the word itself, tell you that visualisation is at the heart of the methodology. Since a ‘workflow’ is precisely the series of steps that any piece of work goes through from conception to finish, you are not even doing Kanban if you haven’t structured your world around an Agile Board (also known, not surprisingly, as a Kanban Board). You would therefore expect practitioners of this philosophy to have thought considerably about how best to create and use such boards, and to be somewhat refined and advanced in their practice of it.

But what about the dominant methodology, Scrum? A search through The Scrum Guide 2016 contains not one mention of the words ‘visualize’, ‘workflow’, or ‘board’, so the contrast with Kanban is immediately clear.

Below are some excerpts from the Guide that could be implemented via something like an Agile Board, but they could be implemented in other ways, even ones that are not visual at all.

The Development Team uses the Daily Scrum to inspect progress toward the Sprint Goal and to inspect how progress is trending toward completing the work in the Sprint Backlog

[In] the Sprint Review… the Product Owner explains what Product Backlog items have been “Done” and what has not been “Done”;

Monitoring Progress Toward a Goal: At any point in time, the total work remaining to reach a goal can be summed…  This information is made transparent to all stakeholders.

At any point of time in a Sprint….the Development Team tracks [the] total work remaining…[to] manage its progress.

More promising is the language used to describe two Scrum ‘artifacts’, the Product and Sprint Backlogs:

The Product Owner [ensures] that the Product Backlog is visible, transparent, and clear to all, and shows what the Scrum Team will work on next

The Sprint Backlog makes visible all of the work that the Development Team identifies as necessary to meet the Sprint Goal. [It] is a highly visible, real-time picture of the work that the Development Team plans to accomplish during the Sprint

This is more like it! But before we get too excited, remember that a Backlog is really just an ordered list, and lists are hardly rich visual experiences. This isn’t quite a direct command to use something like an Agile Board.

And finally there is this:

Significant aspects of the process must be visible to those responsible for the outcome.

This is the most promising allusion, but no more is said in the Guide – the very next sentence goes on to talk about agreeing terminology and a definition of done, which (while definitely important) are clearly nothing to do with visualisation.

In summary, there’s nothing in the Scrum Guide that stops you using an Agile Board, but there’s also nothing that requires or particularly promotes it, and so you might expect that teams following this programme may try some form of work visualisation, but might not have developed it particularly far – which is exactly the situation commonly found in most software development teams. Thus there is a plausible cause-effect relationship between the low prominence given to visualisation techniques in the dominant methodology, and the somewhat half-hearted attempts at a fully-functioning Agile Board that we see in many real software teams.

No article comparing Kanban and Scrum would be complete without mentioning the best short guide to the two; Henrik Kniberg’s masterful free booklet, Kanban and Scrum – Making the Most of Both is a must-read for anyone interested in the topic, chock full of insights and wisdom, and highly recommended.

[1] a constant nightmare for Brits writing on this subject is having to switch between UK and dominant US spellings of key words

Agile Boards 101 – why visualisation is critical

Human beings, like all primates, are primarily visual animals. We depend on our eyes far more than our ears or noses to apprehend and understand the world around us.


This means that, to a pretty good first approximation, we are aware of, think about, and respond to (or, in other words, ‘manage’) what we can see, and ignore what we can’t. Since it’s best to work with, not against, the grain of millions of years of evolution if you want to get stuff done, the Prime Directive of effective management is to make your work visual.

By representing your work visually in a unified way across all the group(s) of people involved in that work – those who request it, do it, check it, manage it, pay for it and benefit from it – then all these people will have a verifiably similar understanding of that work: what’s been done, its current status, what’s coming in the near/middle/far future, what milestones have been achieved thus far and what the problems exist. Without such a common understanding of the world and its challenges, these multiple people are not a team in any real sense of the word, and are correspondingly unlikely to make systematic progress together.

It is thus no exaggeration to say that the common understanding of work, that can only be achieved by making work visual, is how you build effective teams, and teams are what allow you to make progress and deliver what the organisation needs. It really is that important. In my experience very few teams have ever given their work visualisation much thought, and as a result not that many do it well, leading to poor coordination and massive waste.

To summarise: in complex fields such as professional software development, if you want to act like a team and manage your work effectively to make any progress, and do not want to risk wasting all your money and time, you must find good ways to make your work visual.

So what kind of visualisation are we talking about? The relevant characteristic of software development is that work passes through a series of discrete steps, moving through many hands as it does so, both between teams, and within teams (the typical sub-teams in software development being: Dev, Test & Product). While this flow of work has some loops and eddies in practice (ie parts of it are iterative), there is still a clear direction of travel, broadly: idea generation and selection – fleshing out – coding – checking – sending live (= done).

Such step-wise work with multiple handovers is best visualised on a two-dimensional grid, where the vertical columns represent the steps that the work flows through, from left to right (or right to left if everyone’s native language is Arabic or Hebrew), and the individual chunks of work are represented by cards or tickets that sit in the columns. Such a board goes under many names, perhaps the most common being Agile Board or Kanban Board. Although the latter is probably the most accurate term, the principle of visualisation is broader than any one methodology, so I will use ‘Agile Board’ by preference.


As always, lousy implementation will ruin even the very best of ideas, so such an Agile Board needs to be set up, maintained and used well, and I will write a series of articles on this topic.

In conclusion; proper work visualisation using Agile Boards is the arguably single most important component of efficient management of software development. Only by leveraging our most important sense, vision, can you effectively create common understanding and a sense of teamwork in complex organisations. Most software teams try to implement it to some extent (especially if they are more influenced by Kanban than Scrum), but few think about it deeply and many attempted implementations are deeply flawed, which goes a long way to explaining the wasted money and poor outcomes of much professional software development.

As an industry, we need to do this better.