Use of colors for your tasks: To color or not to color?

The use of a physical board in Scrum has the advantage of using post-it notes for the tasks needed to get stories done. While you have a multi-disciplinary team, these tasks are of different types of work;

  • You probably need some documentation writing to explain to the end-user how they should use the product.
  • You may need some testing of the product that you deliver
  • You probably also need to write some code
  • There might be some database work required
  • And maybe even some analyzing, some meetings, some support or maintenance work, some review and some demo preparation.

Some tasks might even be part of multiple types. If you start a task ‘Code review of the new code for the login portal’: Which type is that? ‘Review’, ‘Test’ or ‘Code’? The use of colors can help you see the bottlenecks in the team composition, but it might also get you into the trouble of being too strict on definition. So, what’s the good practice? Is it a good idea to use the colors, or should we just not care too much and just do the work that is needed to get the story done?

Does the maturity of the team impact the use of colors?

The maturity of the team does impact the answering of this question. When a team is just starting to get used to the scrum framework, it is probably wise to be strict on color usage. You already have a strict and rigid framework in-place: the Scrum framework. When you start off with Scrum, you should just follow the rules to become more Agile faster. When you get better at it, you can try to alter these rules to your needs. This way-of-thinking is part of the Shu-Ha-Ri model out of Japanese martial arts (link: ) and was firstly introduced to Agile by Alistair Cockburn in his book Agile Software Development.

So, when you are in a more mature team, you also get more freedom to alter the scrum framework to your needs. Color usage for post-its is in the same category. When a team starts with Scrum, color coding will help out to make bottlenecks transparent. It will show you valuable information that can be used to get more working products at the end of the sprint. After all that is the real value of working in an Agile way: You will get more valuable and done products that are ready to go to a production-like system. When you make good use of a Definition of Done, this product will also be of good quality.

So, how to do this?

Doing this isn’t really hard. Start at the sprint planning and take 4 different colors of post-its with you. When it is clear which user stories will be delivered in the coming sprint, the team will need to define how to get the stories done. They define the tasks. Please ask the team to use different colors for different work and let them define any missing types of work. By using post-it notes during the planning session, the whole team can write tasks simultaneously. Besides the colorful overview of the sprint, you will also gain some speed. The result will probably look like this:

So, when is the team mature and when do I skip the colors?

When the team is more mature, you will find out that they do not need the colors anymore. They know what is needed for every story from a quality perspective (they know what is on the DoD). Also they probably know which recurring tasks are needed for the job (i.e. adding the unit test to the regression test, creating the release notes, altering the user documentation). That will probably also result in less need for color coding the tasks.

The correct answers to the question above are:

  1. It depends.
  2. Let the team decide.
  3. Use common sense.
  4. When the team is mature enough to define their own ground rules

It might happen that you are too strict in definition. So the question arises: ‘What will do with this code review-task? Is it part of type ‘Review’, ‘Test’ or ‘Code’? Well, in the end it doesn’t matter. In any case you will see the bottleneck, independently of what type you choose. So, use common sense, and do not argue too much on the exact color type definitions. It might be more effective to produce some more working software…..


Posted in Development team, Scrum.

Leave a Reply

Your email address will not be published. Required fields are marked *