Kanban Board

In the earlier entry on kanban.  I wrote about its assumptions. Today, I would like to describe a fundamental element of kanban: a board.

This board presents:

  • Who works on what
  • What you are working on
  • How many tasks are fulfilled at the same time.

The board visualises the degree of task fulfilment.

I will write more about tasks in a forthcoming post. I would like to mention that tasks in Kanban are cards which should/may include:

  • New tasks
  • Task description
  • ID from electronic systems (e.g.: JIRA)
  • Deadline
  • Who works on the task
  • Task type.

Obviously, these are sample attributes. The team should determine itself what attributes it needs.

Sample kanban card:

The task card is posted on the board.

The Kanban Board

The Kanban Board is a white board in the beginning. At subsequent stages of creating the rules for the team work, columns and tasks are added.

The process of software management may be compared to the process in a factory. We perform similar activities step by step. Obviously, acting step by step does not have to generate the cascade manufacturing of software. I look at this process like an activity in a factory, where at each assembly station a new thing is added.

Typical stages on kanban board are as follows:

  • To be done – waiting for starting work,
  • Analysis
  • Programming
  • Testing
  • Done.

Of course, as part of the agile trend, a basic board may have the following columns:

  • Product register
  • Work
  • Done.

The flow on kanban board is from left to right. The first column always contains things/tasks to do. A key to kanban is precise determination when work is regarded as completed and when it may be handed over to a subsequent stage. In Kanban, work is not complete until there is value for the customer or a person implementing another stage. The change of a stage (column) of task implementation should be subject to specific rules, which determine the criteria for transferring a task to another column.

Additional verses may be added on the board. Additional verses are other activities performed by the team. Such tasks are “throw-ins”, urgent tasks and other activities, which must be done by the team. It is worth mentioning that maximally one/two tasks a week can be urgent tasks. Otherwise, urgent tasks steal the time intended for work.

It must be noted that not all the tasks will go along the same path. Maybe “error” type tasks will not go back for analysis. It is worth underlining such a task in colour. The team should determine the rules for this type of threads.

Finishing the thread with the board, it is worth mentioning that the board ought to be designed by the team members who will use it. Thus, they will respect the work rules.

Board and queues

Queues on kanban board are used for visualisation of the work to do. A queue is tasks to be fulfilled as part of an activity described in a target column.

In other words, queues/buffers are columns, where work is located, which at the previous “active” stage was completed and awaits transfer to another stage of an “active” process. Work waits there for a gap in the next process step (usually according to the FIFO rule).

In the drawing above, I created the Buffer column. Frequently, this column is called To X where there can be “to programme” or “to analyse”. This column is the already mentioned buffer.

The board perfectly visualises the project state.  The flow implemented allows the work status and any accumulation of work to be seen. Work accumulation is generally displayed in the buffer column. There is a queue of tasks to be done. An excessive number of tasks in a queue is a signal which anticipates problems in the process.

I think that it is good to meet every morning in front of the board (electronic or physical) and talk about currently fulfilled tasks. It is a good time for checking who and how many tasks has in a queue and where the process bottlenecks are located.  Similarly to SCRUM, such a meeting should take maximally 15 minutes.

Everyday meetings with the board facilitate communication within the team and simplify solving problems connected with the software manufacturing process.

And how does your board look like?

 

More from my site

  • Kanban Reports Process management is a midway to success. The second midway is process monitoring and drawing conclusions. In Kanban, there are indicators, which enable process monitoring. They allow the […]
  • Kanban Tasks In the previous entry, I wrote about the task board in Kanban. Now I will add some words about tasks and task cards. Kanban tasks are specified by means of a card. Many people prefer […]
  • KANBAN – basic terms and rules This article opens a series of texts on Kanban. I am planning 7-8 texts in this area, which will be posted every two weeks. Let us start from the beginning. What is […]
  • Kanban Bottlenecks Queues and WIP limits, which I discussed in the previous posts,  make up a chief indicator of problems in the flow. They show bottlenecks and when they are going to form. Bottlenecks are […]
  • Kanban Workflow In the preceding Kanban post, I wrote about partially done work. I wrote that it is worth limiting partily done work. The WIP (Work In Progress) which is too high results in the fact that […]

Leave a Comment

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

Scroll to Top