Tester Contributions to Scrum Conversations
Scrum is one of the most popular ways for development groups to start down the agile road. The technical team meets every day and answers a few questions about what they were working on yesterday, what they are working on today, and if there is anything blocking work.
In my experience, however, testers join this framework as an afterthought, and sometimes they aren’t quite sure how they fit into the Scrum development flow.
My first experience with Scrum was meeting with a few developers each morning. We went around the room to answer the daily questions, starting with the developers, then the product people, and then the testers. Our developers and testers often had detailed discussions about what they were working on. Sometimes a development was on time and we were burning down on schedule. Other times, a developer would discover that we had completely forgot about a task needed for a new feature. Important information was being shared with the group.
Testers’ status updates were usually along the lines of “Yesterday I tested the new discount feature. Today I am testing the report for discounts. No blocks.” That status answers the Scrum questions, but it doesn’t add any new or useful information to the conversation.
Scrum is more than three questions, and testers are in a position to understand the project better than anyone else on the development team.
More recently, I was working with a small development team. The six of us sat together at a pod of desks. Each morning we would review the backlog to see what everyone was working on. Ideally, each person only had one task in their queue at a time.
Developers would talk about what they were working on, but the conversation was focused on our drive to production rather than specific tasks. As the tester on the project, I was able to notice that a deliverable had been sitting in one column for a while. After bringing that up we discovered that it was dependent on a piece of code that wasn’t yet in a developer queue. Another time, I was working on an advertising campaign feature and discovered that live campaigns could be edited in certain scenarios. This was undiscovered scope that we were able to address quickly.
Over time we got to where we didn’t need the meetings at all. Sitting together every day helped us develop a flow. Rather than waiting until the next morning to bring up a dependency, developers would just talk with each other. If I found a bug that seemed like it would significantly increase scope, I would talk with a product person and a developer.
Scrum has a few basic principles: reduce work in progress, deliver software more often, and do those things by collaborating. Testers are usually in a better position than anyone on the team to discover and contribute important information.
At your next standup, try to say more than “Yesterday I tested this, and today I’m testing that.” You can probably change the trajectory of a release by sharing something important only you know.
