Steve Fenton

Agile boards: Rows vs columns

Take a look at your Agile boards and count the number of columns. Is it more than three? I would like to challenge your board if you have more than three columns; “To Do”, “Doing”, “Done”.

A common fourth column is the “Testing” column, but if you have one of these you should consider removing it. This isn’t because testing isn’t important or shouldn’t be represented on the board, but because it is better represented horizontally rather than vertically.

A column on the board forces a process to run in sequence, so a test column will cause testing to start only when programming has ended, which isn’t how we want to work in an agile team.

Instead of a testing column, testing tasks should be discovered and visualised just like programming tasks. Here are some of the benefits to using this approach with your agile boards.

  • Planning – if you are breaking a story into programming tasks, do the same for testing tasks. You may just end up with “Write test cases”, “Run test cases” – but not every time. If everyone understands the testing tasks, the sizing will be better informed.
  • Concurrency – the testing tasks can start on day one of your Sprint and don’t have to wait for programming to be completed.
  • Feedback – if the testing tasks start sooner, there is more chance that the tests will influence the programming tasks.
  • Visualisation – by using different colour tokens for programming and testing it is possible to see progress on the task board.

Of course, this isn’t specific to testing. Whenever you think about adding a column on the board, bear in mind that it tends to force sequence in the process and that rows don’t. You should be able to avoid a fourth column unless you are dependent on people outside of the Scrum team, in which case the column will highlight the sequential nature of this interaction (as well as the resulting delays).

So take a look at your board and see if there are any columns that could be erased.

Written by Steve Fenton on