Standup meetings are a daily (or weekly) staple for teams practicing agile software development. Ten to twenty minutes spent discussing what everyone is currently working on and what issues stand in the way is massively important when teams are focused around productsnot rolesand working on 2-4 week cycles.

Because scrum teams involve business analysts, developers, and QAs, clear communication is key. Everyone has a different perspective, which makes reaching a consensus challenging. Testers working with agile methods have the opportunity to clarify and guide requirements, assist with product ownership, and create user stories in addition to tracking bugs.

The increase in skills required from QAs by the agile methodology is exciting and rewarding. Testing is no longer “left until the end.” Testers aren’t kept separate from other roles and have more input.

Daily or weekly standup meetings are a place where all of these new skills and opportunities converge. To be the guardians of quality in an agile team, QAs need to contribute to standups and help make them a really valuable use of time. Here’s how testers can make themselves heard during standups:

Identify and prevent blocks

There is some disagreement on what exactly, should be discussed. “The Three Questions” are a commonly used format for conducting standups. Everyone takes a turn answering the following:

  1. What did you do yesterday?
  2. What are you going to do today?
  3. What blockers, if any, do you have?

But Jeff Sutherland, the inventor of the daily standup doesn’t want these meetings to only produce status updates.

That’s why it’s so important to use all three questions as an opportunity to bring up blockers, or other things that require collaborationnot just question #3.

Consider this example response to question #1:

Yesterday I worked with John to figure out the reproduction steps for Issue 0201.

Sure, that to-the-point response might help keep the meeting under the desired 15 minutes, but it’s not going to engage anyone. It’s not going to immediately and obviously remove any blocks. When reworked, the response becomes:

Yesterday I worked with John to figure out the reproduction steps for Issue 0201. The issue log has been updated, so Jane and Mary, you should now be able to reproduce that. But let me know if you’re still unable to.

By clearing blocks for other people (and doing so obviously, transparently, and by name) you can shift the energy of the entire meeting. And energy is what standups are all about.

I want teams emerging from that meeting saying things like, “Let’s nail this. Let’s do this.” The team needs to want to be great.

Jeff Sutherland, CEO Scrum, Inc.

Focus on communicating, not fixing

Successful standups are engaging. They involve everyone present in active and direct ways, but they are not the place for decision-making or problem-solving.

Managers provide the most value when they remove blocks for other people. Standups allow for everyone to have a chance to clear the way for someone else. Just not in the moment. Otherwise, how could the meeting possibly be kept to under 15 minutes? If items are discussed in detail, how could the meeting NOT waste someone’s (or lots of people’s) time?

When the solution you have to share takes longer than a few seconds, don’t share it just yet.

Standups should stay focused to giving current status and raising issues that impact others or could be solved with the help of others. If someone is going to get help on a particular issue, the folks involved should circle up after standup is over to dive deeper, and not derail the conversation in the middle of standup.

Teel Love, Senior Product Analyst at Clear Capital

No matter the role, everyone present at a startup has to be mindful of this. A QA analyst might communicate a need for an automated script that identifies data corruption without attempting to ask which scripting language or program should be used. What’s most important is to communicate the WHO but not necessarily the HOW. If you need help with something, just say so. Then others on the team can offer their help.

Standups are for micro-commitments to each other. Not for decisions about projects and programs.

Johanna Rothman, Rothman Consulting

One easy way to keep everything on track is to always schedule a follow-up meeting that happens immediately after standup. It could be an extra 15 minutes, wherein anyone who needs to can stick around. Having this scheduled makes the actual standup go pretty quickly, because one team member can ask for help and another could say “I had the same issue yesterday. I’ll tell how I fixed it during the follow-up.” Anyone who’s interested can stay, and everyone else can go.

For small teams, follow-up meetings might not be necessary. What really matters is that the promise to follow up is made (whether it later take place in Slack or during lunch), rather than the solution being described during the standup.

Be ready to pivot and re-prioritize

Some companies have multiple standups for different scrum teams all over the world. Other companies are so small that they can bring in even more roles into the meeting, like customer support or sales.

In this case, QA engineers have even greater opportunity to guide the success of the product. In a standup, they might hear directly about a major customer support ticket that came in that morning. QAs might need to re-prioritize their day following the meeting to thoroughly examine the issue.

Because business analysts are typically involved in standups, larger pivot points can also be identified revealed. New changes in requirements that require updates to test cases might be brought up. Since agile teams practice shift-left testing, the early creation of test cases and their continued maintenance is critical.

Participating with an active mindset, ready to pivot as needed, is an absolute must.

Done right, standups can make teams more productive and more invested in their work. Done wrong, they can feel like a boring interruption to the day. For their benefit of everyone present, testers need to contribute to the removal of blocks, give and receive commitments to help, collaborate and communicate quickly, and be ready to make adjustments to their test plan as the cycle moves along.

Jumbotron image

For testing that integrates seamlessly with your existing tools and your awesome teams, get in touch with us.

Dayana is a QA engineer turned technology writer living in Milan, Italy. She's always down for a smoothie.