There are many ways to organize your kanban (or scrum) boards. One difference is the meaning of colors of cards. Here are some examples of how we can use colors so that the board tells us as much as possible about the current work.
Size of task
One team I worked with used the following color code:
| L – large task | |
| M – medium task | |
| S – small task | |
| bug |
As you can see, for features colors of cards answer the question “when it will be done” (well, at least they give some hint about completion time…) which is quite important for PO. The red color is special – it says something is a bug without specifying how long will it take to fix it.
This worked pretty well. For large tasks, we usually put them on the board but we also put their subtasks so that we could observe the progress.
Type of task
| technical task | |
| maintenance task | |
| new feature | |
| bug |
A different approach. This time the colors say nothing about the (expected) completion time, but allow to understand what type of tasks is prevalent: is the team mostly fixing bugs or maybe we are working on our architecture to prepare it for the expected increased number of requests?
Green and red are obvious but let me say a few words about technical and maintenance. It is not obvious which tasks should go where, but the criteria we use is the purpose of the task. Usually, non-feature things requested by customer support ended up as maintenance and things like redesign were treated as technical. To be honest there was some confusion about these two types (especially when we begun) but now it is not a problem anymore.