Scrum board columns

There's no one-size-fits-all approach to how to structure your boards, or however you are representing your Sprint Backlog.

In my experience, the best approach is to model the team's workflow and experiment with different levels of granularity. If the workflow is too granular, it will become hard to update and the team will either take a lot of productive time to make sure the boards reflect reality or the board will be out-of-date and not useful. If the workflow is too abstract, then it won't serve as a useful information radiator for the team to evaluate their progress and make decisions. The only way to find the right level of abstraction is to experiment.

Use your Sprint Retrospectives as an opportunity to evaluate the current state and make adjustments. Then, give it at least a Sprint or two to watch the experiment unfold and reevaluate. The only time I'd be concerned is if the team is unable to make a decision because they are striving for "perfect" and not "good enough" to enable their success.

Our teams have started requesting additional columns such as Dev done and Ready to test, rather than just having "In Progress".

Requesting additional columns from whom? Shouldn't they be managing their own workflow? If they wish to experiment with the kind of transparency you refer to, why don't they just give it a go?

I second @Thomas' response.  In the teams that I work with the board evolves over time.  There may be a use for one specific column to help the team improve the workflow, but that column's use could become obsolete once a team "perfects" their system of work. 

Don't over complicate it but don't make it too simple.  The Scrum Guide doesn't mention a board anywhere.  It discusses making the work visible. Many teams and organizations have found that a board is useful for making work visible and for helping the Developers manage their workflow. 

Since the Sprint is considered the Developer's domain, let them experiment with how they want to work.  If adding columns to their board is something that they feel is useful, then facilitate the changes.  Then help the team inspect and adapt continuously. 

Forgot to mention this. 

I know in scrum there is no such thing as Dev & Test however as well all know there is such terms when doing the actual work.

In the Scrum framework there is no such thing as Development and Test teams.  But the Scrum Guide does state this in the section that describes the Scrum Team. 

The Scrum Team is responsible for all product-related activities from stakeholder collaboration, verification, maintenance, operation, experimentation, research and development, and anything else that might be required. They are structured and empowered by the organization to manage their own work. Working in Sprints at a sustainable pace improves the Scrum Team’s focus and consistency.

So the previous discussion about allowing the Developers to form their board in a way that benefits them plays directly into that statement. 

Do it.

The board should be how the team wants to represent their workflow. If they want these columns, they should have these columns.



But ... the team may want to make a Definition of Workflow, and define how items go in and out of the columns (how many are allowed to in the column, and how are items chosen?).

Hi all, thank you for the quick replies and you have confirmed what I was thinking. I was asking as I'd heard members of another team saying we're not doing scrum by adding these extra columns, this was when I referred to the scrum guide saying it doesn't state what columns should be used, and I did say the Developers own the sprint backlog.

I would never want to prevent the scrum teams trying something and with the columns I felt the team owned these to help with transparency. 

We did start with the basic columns, which then the development teams asked for additional columns to help keep track of flow. We will keep inspecting and adapting but happy I'm giving the best advice.