I recently had an experience in a scrum team where, at the end of every sprint, the testers were getting flooded with tasks. The work wasn’t flowing to testing throughout the iteration, meaning that the process was essentially a two-week waterfall but without an allowance for testing to finish after development. As a specialist tester on the team I wanted to see a constant flow of testing activities.
The “testing bubble” was acknowledged as a problem and the team used a retrospective to agree that the root cause was having too many stories in progress at once. As each sprint progressed, more and more stories were pulled into development, which increased context switching in the team and jammed the workflow. When we thought about why the work in progress was so high we identified three key areas for change.
The first was that individuals were hoarding tasks. People were pulling three or four items into progress at the stand up meeting. This meant that when someone was available during the day to pick up a task it seemed that none were waiting. Though tasks were in progress on the visual management board, they actually sat idle in a queue with another team member. Often the result was that the available person would begin a new story in order to have something to work on.
The second was that the team were focused on attempting to cover the broadest scope possible within an iteration, not on seeing individual pieces through to completion. It was hard for people with capacity to resist the urge to pull in more work in an area that they were comfortable, with an eye to achieving a larger number of stories during the sprint, rather than swarm on a task outside of their primary expertise to see a story completed. Again the result was that a person would start working on a new story.
The third was examining the reasons that stories were being blocked during development. At the start of each sprint the team didn’t visualise interdependencies between stories. They would start on story 44, complete a couple of tasks then discover that they were blocked until story 49 was completed. Story 49 would commence, then part way they would realise they needed story 54 first. The result of this just-in-time analysis was an increasing number of partially completed functions. As the sprint neared completion these dependencies would unwind and the testers would be overwhelmed as everything exited development in rapid succession.
None of these behaviours were specifically a test problem and yet they were causing the biggest problem for testing. This illustrates that It’s important to remember, particularly in an agile environment, our remit as testers is wider than we think.
The scrum process offers a scheduled forum to examine how we work. As a tester we can use the outcomes of a retrospective to improve our working conditions in the sneakiest ways. A tester campaigning for change on the points above can alter behaviours and process beyond the traditional boundaries of a testing role, but where there is significant benefit to testing. Lets all look to influence the wider process when attempting to change the way we work.
About the Author
Katrina Clokie is a tester from Wellington, New Zealand. She is a regular participant of KWST, co-founder and organiser of WeTest Workshops, and has recently been convinced to start blogging and tweeting about testing. You can find her online @katrina_tester and http://katrinatester.blogspot.
If you have a story to tell or a point of view to share, we’d love to hear about it. Send it to us here!