One common practice found in many Scrum teams is the use of a test column on their Scrum board. While the intent behind it good, to streamline the testing phase, there are compelling reasons to reconsider the necessity of this column.

Why is there a test column ?

The test column provides a dedicated space for testers in the workflow. This highlights their crucial role within the development team, where testing is not merely a final step but an integral part of the entire development process.

Additionally, the test column enhances the visual representation of work on the Scrum board. It immediately clarifies when items are in the testing phase, improving the overall understanding and monitoring of progress.

Another important function of this column is to make responsibilities within the team visible. Team members can easily identify who is responsible for performing tests and in which phase of the process each item is located. This contributes to improved coordination within the team.

Problems that can occur

The presence of a test column can raise some problems.

The test column can create unintended silos within the Agile team. This means that developers and testers find themselves in their own columns on the board. This can hinder smooth collaboration. The process can evolve into an ‘over the wall’ approach, where developers hand off their work to testers without involvement in the testing process.

This separation can also encourage the not my responsibility syndrome. Team members may use the excuse that they are not testers and, therefore, not responsible for testing. This looks like the waterfall model of the old days.

The presence of a test column can slow down the pace of a story. Testers can become a bottleneck, especially in teams with multiple developers. If testing only begins after development is completed, it can lead to delays in delivering functional software.

Finally, test activities may be initiated too late in the process. If testing only starts after development is finished, it can be more challenging to identify bugs. Which can potentially harm the overall efficiency and quality of the development process.

Simplifying the Scrum Board

A Scrum board with numerous columns, including “Test”, “Review”, “Merge”, and “Deploy” might lead to clutter and complexity. Streamlining the board with less columns makes it more manageable.

To make test activities visible on a Scrum board, consider representing them as individual sub tasks of a user story. Each with its own dedicated card. This approach enhances transparency and ensures that testing activities are clearly identified and tracked.

By doing so, you maintain visibility into the testing process without the need for a separate “Test” column. Each test-related subtask becomes a part of the user story’s journey from start to finish, promoting collaboration, synchronization, and a better understanding of the work’s progress.

The simplification of your visual workflow can lead to a team that is more focused and productive, as reduced overhead enables team members to concentrate on their core responsibilities without the burden of managing a complex board. This clarity encourages better collaboration and teamwork.

To promote parallel work and collaboration, consider integrating testing seamlessly into the development process. This way, developers and testers can work concurrently, which not only accelerates progress but also facilitates early issue identification. If you keep the test column, the testing work is always behind the development process, which is a bad practice.

Better collaboration between testers and developers results in continuous testing throughout the development process, rather than isolating it in a separate phase.

Conclusion

In a surprising twist, the key to enhancing visibility and optimizing your Scrum workflow might very well be the removal of the test column. Integration of testing and related activities can help your team maintain a higher level of agility. Remember, agile practices are meant to be tailored to your team’s unique needs and goals, and sometimes, doing less can yield better results.

References