Status Tags and the Three Columns

“Less is more”. You heard this before, right?

This applies particularly to visual management. It is very easy to generate noise by creating visual elements that are not strictly necessary. When designing our information radiators, we should always be careful not to create waste. And any visual element that doesn’t add value is waste.

Of course, sometimes it’s not that easy to figure it out. For example: suppose you run out of yellow Post-it’s, and you see some green Post-it’s lying around. Should you use them, or is this waste?waste

By using another color, you are creating “something”. There used to be one color, now there are two. People will look at the board and wonder: “What does green stand for? What’s the difference between green and yellow?”. And there is none, you were simply out of yellow. So in this situation, using green is waste. You are also killing off your possibilities of giving green a specific meaning in the future, which you might will need.

But on to status tags and the three columns, the main topic of this post. It’s time to design your taskboard, and you have to decide the most basic of things: how many colums do I make, and what do I call them?

If you are doing Scrum, and you agreed with One Day Tasks, you will probably be tracking the flow of tasks (not stories) across your board.

What’s the simplest solution that will work?

A unit of work can have three basic states: “Not Started”, “In Progress”, and “Finished”. Most taskboards that have more than three columns are breaking up “In Progress” into intermediate, sequential phases. Typical example: “To Validate”.

There are many reasons why I would try to avoid using additional columns. It promotes specialization and local optimization. It creates two processes and a buffer where there could be a cell and single piece flow. It’s waterfallish.

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. All this is waste.

Blue team board

A good way to eliminate the need for extra columns is to use status tags.  For example, instead of adding a “To Validate” column, we can solve the same problem with a PLEASE TEST status tag that you stick on the task. Practically any sub-state of “In Progress” can be represented by these status tags; which are smaller, less intrusive and more flexible visual elements than columns. They are also color-coded which makes them even more powerful from the visual perspective.

So unless you’re into Kanban and you really know what you’re doing, I highly recommend you stick to the basic 3 columns. (And we’ll discuss Kanban another day, because I think status tags and the 3 columns might also be applicable there. For example, you can limit work in progress by limiting the number of available status tags.)

Status tagsThe Post-it’s I use for status tags are product number 653, 51 x 38 mm in size. I use two different color sets, that gives you around 6 total usable colors (there is some overlap between sets). I also put a very small piece of Scotch Magic tape on the top, because they are not Super Sticky.

The status tags I use will be discussed individually in separate posts.

Tags: , ,

  1. Dadi’s avatar

    Hi Xavier,

    What do you mean when you put status tags on _tasks_? ‘Please test’ that the portion of the story that I finished by doing the task works?

    Really great stuff your doing on this site!


  2. Xavier Quesada Allue’s avatar

    Hi Dadi,
    In the examples I show, a task represents a piece of work the team has identified as necessary to complete a Story. “Please Test” on task level thus means that a certain team member wants another team member to review or validate whatever work was done to complete the task. It is an internal team signal, that should normally trigger a conversation between the person who completed the task and whoever will validate it. If the story was broken up into tasks that are indivudually testeable (for example, maybe steps in a workflow) then Please Test could very well mean what you wrote. But it is not always feasible to break up a story into individually testeable tasks. So a Please Test tag could also mean “please review my code” or “please review my design”… it’s all up to the team, the project they are working on and how they decide to approach it. The important thing is giving the team a visual flag they can use to indicate they want a piece of work reviewed by someone else within the team, thus eliminating the need of a “Validate” column.


  3. Marcelo’s avatar

    Xavier, como estás. La verdad que pasó mucho tiempo desde que me enteré tu block, hasta que pude dedicar unos minutos a leerlo.
    Finalmente, me lo deboré, no podía parar de leerlo.
    Gracias por las ideas, muchas ya las estoy aplicando hace un tiempo, y muchas otras las voy a tratar de probar para ver como me funcionan.

  4. Xavier Quesada Allue’s avatar

    Gracias Marcelo, un abrazo.

  5. Metin Gucer’s avatar

    Hi Xavier,

    I really liked your ideas on your web site. However, I had to disagree with your approach on this case. Having status tags can also cause losing some information from your scrum. During the scrum process, I also like to see the number of tasks needs to be tested and also number of bugs found for each task. Status tags could be removed from the task and at the end of the sprint, some measurement points could be missing.


  6. Cesar’s avatar

    Hola Xavier, muy interesante tu blog! estoy aprendiendo mucho leyendo tus articulos y ahora voy a comenzar a implementar Scrum por primera vez en la empresa en la que trabajo.

    Creo que he entendido bien todos los elementos del Scrumboard, excepto uno. Bajo que criterio se dividen las tareas en filas? En las fotos que colocas siempre hay 3 columnas (esto si lo entiendo) y 5 ó 6 filas. Si pudieras darme un ejemplo por favor.

    P.D. Puedes responder en ingles, no hay problema.

  7. Xavier Quesada Allue’s avatar

    Hola Cesar, las filas son historias de usuario. Cada historia de usuario a su vez se divide en tareas. Para más informacion te recomiendo leer el libro “Scrum y XP desde las trincheras” de Henrik Kniberg. Xavier