Agile coach and visual management guru, Xavier Alue, is adamant that the optimal number of columns on a scrum board is three. Not Started, In Progress, and Finished. Anything more is wasteful, he says.

His reasoning for why this should be, however, is not entirely clear. One of his complaints is that it's "waterfall-ish" which, as I'll explain later, is not reason enough on its own to avoid doing it. Then he says this:

"But the most important reason -from the visual management perspective- is that it creates extra visual elements (more columns). It also uses more taskboard real estate, which can be scarce."

This is tautological - you shouldn't use extra columns because it creates extra columns. It also only addresses the limitation of physical task boards, something we may not be concerned about with digital task boards. The conclusion one draws from his reasoning is that you shouldn't use extra columns because he says you shouldn't use extra columns. Not very convincing.

To be fair, I'm a huge fan of Alue. His Visual Management Blog, although no longer regularly updated, still plays host to a wealth of practical - and specific - advice on visual management techniques. I've read every article several times. This one, however, always bugged me.

Some processes in software development are sequential and, as a consequence, waterfall-ish. That doesn't make them incompatible with Agile methodologies. Tasks need to be tested before they're deployed. They need to be deployed before they're considered finished. Alue recommends using Status Tags for these intermediate stages, which is a great idea. The purpose of this article is to delve more deeply into why this is more than just good advice and should be considered a best practice. On a side note, I also happen to agree with Alue that, for most teams, three columns is the optimal number.

The Real Reasons Why More Columns Is Not Necessarily Better

When you strip away all of the lean philosophy bullshit, you find that the actual purpose of visual management is for team members to better communicate information - both to each other and to management. Coordination and collaborative benefits are merely follow on effects of the communication as it occurs. That's because the information being communicated is an aggregate of the continuous, collective input and feedback of several individuals working together to achieve a common goal. All visual management boards should therefore be considered communications tools first and foremost (Alue refers to them as "information radiators"). What is the current status of the project? Are we on schedule? Are there any blockers looming that we need to address? Does everyone know what they - and everyone else - is supposed to be doing today? Tomorrow? Next week?

From this perspective, clarity and conciseness should be the driving considerations when designing your visual boards. Communicate only that which is necessary to keep everyone on the same page and the project moving forward. Anything more creates opportunities for miscommunication, misunderstanding, error, and waste.

Agile methodologies, and Scrum in particular, are supposed to favor people over processes. In small teams, this philosophy often prevails. As teams get larger, and the number of projects and their scope increases, people begin to take a back seat to process. Management suddenly requires a unified view across multiple projects and the ability to quickly roll up project status with breakdowns by user, team, and, yes, intermediate work-in-progress (WIP) steps. These administrative needs lead to conflicts with established methodologies, burdening the communications process.

For this reason, considerable thought should be put into selecting only those steps which are necessary to improve visual communication. Improve visual communication and, per situation awareness theory, you will improve coordination. The project will stay on course. Anything more is extraneous (or wasteful, as Alue would categorize it).

Digital kanban software greatly simplifies the process of adding task board columns, among other automated tasks. While this functionality is convenient, it comes at a price. It's so simple that there's little-to-no consideration given to how those extra columns will affect workflow and usability once they're implemented.

The problem with most digital visual management systems is an over-reliance on flexible design that ignores, or worse, completely disregards the need for structure and standardization. Pen and paper-based task boards are static, so once they're laid out that's pretty much it. Changing the board once it's in use is highly disruptive, but not for the reasons people think. It's not just that the board layout changed. You have altered the communication workflow teams have collectively established by introducing unnecessary steps. If three columns is sufficient for teams to stay on the same page then adding a fourth column specifically to track an intermediate step is superfluous from their perspective.

The ease of adding columns to digital task boards leads to board bloat. New columns get added to track every single intermediate step of the process. Sub-steps are tracked. The task board stretches off the edge of the screen. You have to zoom way out or scroll over to see everything. There's also a weird psychological phenomenon that occurs with task board columns. They appear to carry equal weight. A task placed in the Awaiting Testing column looks equal to one sitting in the To Deploy column, even when they're not. This can give observers the wrong impression about the actual status of a sprint or where a bottleneck may (or may not) be occurring.

Enter Status Tags To Save The Day

Status tags are attached to story points or tasks in the WIP column to indicate which intermediate step is currently in progress or to signal that a downstream process is required in order for it to move forward. Ideally, each status tag should be a different color so that viewers can instantly tell one from another and quickly identify where bottlenecks may be occurring.

The best thing about status tags is that new WIP intervals - or any other special purpose or one-time-use status - can be created or removed easily as needed, without affecting the overall layout of your task board. This makes them minimally intrusive to daily users while still providing the needed status information to product owners, managers, and outside stakeholders. They can be easily filtered as well as rolled up into reports or incorporated into velocity calculations. In short, they provide all the benefits of additional columns, are more dynamic and much less cumbersome.

Are you using status tags on your task boards? How would you like to see status tags implemented in Cnverg? Leave us a reply in the comments below! Or better yet, sign up for Cnverg and start experimenting today!

Recent Posts