Advisable scrum columns for software projects

Question

Our software team has essentially these storyboard columns:

• Backlog
• To Do
• Develop
• Test
• Done

Unfortunately, people inside and outside the team often attempt to affect the board to represent pre- and post- states of stories.

This has resulted in a board which now looks like this:

• Draft
• Backlog
• To Do
• Develop
• Dev Test
• To Test
• Test
• Tested
• Done

While I understand that these are completely reasonable and each team has it's own interpretation of the scrum board, I would like to know if and how anyone running into similar problems has been able to get back to 'pure' columns?

Questions to that end could/would be:

• What is your definition of 'Develop' or 'Test' when in practice each of those can mean potentially 3 different states (waiting for, doing and completed/needs sign off)?
• What is the maximum number of columns a reasonable scrum master should allow on their board, on average?

Answer 1

Scrum doesn't say much about what a task board should look like, so most best practices are taken from Kanban. Some of the Kanban practices that seem applicable to your question are:

• The board should represent your team's workflow so that moving work through it creates a visualization of how the team is working. This creates opportunities to see bottlenecks and other challenges and improve them. Therefor, the columns on your board should represent the steps you go through on your team. This means, by inference:

  • There are no "right" columns. Each team is potentially different.
  • No one outside of the team should ever be changing the team's board.

• Columns are stages of work. There are no queue columns. This means if your steps are "dev" and "test", you should have those two columns. You should not have "Dev", "Ready for Test", "Test". Visual indicators are commonly used like adding a check or dot to a card when it is ready to pull to the next column or an area of a column shown with a dotted line to distinguish if it is ready to pull. This may seem like minor difference, but it can have big impacts if your team starts applying WIP limits.

There is no maximum number of columns, but obviously if it starts getting confusing to use, you may need to revisit your board design. I would also watch that board design does not become an excuse to break core Scrum rules. I've seen teams add extra columns after Done so they can say their work was finished in the sprint, but had more columns to go through before it was really done. At that point, you're losing the value of both Scrum and the board.

Answer 2

It sounds like you are having a PBI/user story go through this sequence of states, and that's probably why they're proliferating.

My teams have two states for PBIs (that are in a sprint backlog): Committed and Done.

Each of those PBIs has tasks (e.g. design the UI, develop the front-end, test) that will get the PBI to its definition of done. Each of these tasks goes through three states: To Do, In Progress, and Done.

In your case, my teams would simply convert some of those states/columns ("To Test" and "Test") to tasks ("Test the product").

Also, your board sounds like a combination of the product and sprint backlogs. The first two states you list (draft and backlog) would not be on our sprint backlogs at all, unless they were truly committed by the team (which is very unlikely for draft stories).