A few years ago, Lisa’s team used an online tracking tool to visualize and manage their work. The team practiced kanban, though they had regular work sessions such as story readiness workshops and retrospectives on a two-week iteration schedule. The project board’s columns include Sized, In Progress, Ready to Merge, Validation, Ready to Release, and Done. Over a few months, the team had ongoing discussions about the Validation column. It regularly got filled up with stories and became a bottleneck and was getting in the way of the team’s desire to deploy small changes to production frequently.
The team practiced ensemble (aka software teaming or mob) programming. Each ensemble, which usually included a tester, used a test-driven approach and incorporated testing activities alongside coding. They did human-centric tasks such as exploratory testing, and automated tests at appropriate levels. The team expected that stories that reached the Ready to Merge column had, in fact, been adequately tested at the story level. So why did stories end up waiting to be validated?
Why a validation column?
One reason was that the product owner wanted to check some of the stories himself. The ensembles sometimes asked him to join them to validate a story before they moved it out of In Progress. However, he was often in meetings and unavailable. Another reason was simply historical. There was a time when the tester was expected to validate those stories. The team embraced testing as part of the development work, but the tester who was on the team a long time sometimes liked to take an extra look at some of the stories when they felt they may be higher risk.
Some stories also needed testing at a feature level, to ensure a feature worked end-to-end. That could be addressed by having separate stories for workflow testing as a “Test this feature” type of story. Lisa also introduced stories that contain exploratory testing charters. Still, the team couldn’t agree to try eliminating the validation column.
So, what happened? The ensembles often ended up spending half a day or more validating stories that were already tested so they could move them from the Validation column. It interrupted their workflow.
Have a conversation
Back in 2018, Janet blogged about whether teams need a testing column on their board. Her conversation with another testing practitioner shows the value of taking a step back to consider more effective ways to organize work and enable more collaboration. She believes a Validation (or to test) column is red flag for teams and would rather see testing activities as tasks within the story. Janet has recommended to many teams to add a To review column which almost every task could benefit from – even testing tasks.
Lisa's team kept revisiting the validation bottleneck at their biweekly retrospectives. Over time, they found that adding individual stories to the backlog for extra testing efforts, such as feature-level testing, was a better way to make that work visible. It also helped with planning, since it was clear that extra time would be needed. They did keep the Validation column but only used it for special cases. For example, if a story depended on work from another team, they put it in the Validation column to coordinate integration testing with the other team.
Make it visible
Different teams represent and track their testing work in a variety of ways. For some, all the testing is encapsulated in the user story. For others, a story’s testing tasks are represented in separate cards or items in their online tracking board.
It’s important to visualize your work and make progress visible easily. Your tracking board can do even more. It can help your team find good ways to weave coding and testing activities together to build quality into your product from the start. As a team, talk about your columns (or stages) to see if they add value to your process, and try experiments to see if your cycle time can be shortened by doing a better job of testing together.