Test Management Best practices

10 min read

20 Aug 2026

Daily standups in QA teams: Do you need them?

A separate daily standup in QA teams may sound ludicrous but Agile practices have long spread beyond software developers. We, however, believe that there is a different way to improve the testers’ output than making them talk to each other every day.

Denis Matusovskiy Author

Wesentliche Erkenntnisse

A standup meeting in QA teams serves three purposes: flattening hierarchy for junior testers, surfacing blockers early, and creating a visible sense of progress within long sprint cycles.
The main argument against QA-exclusive standups is time cost. Fifteen minutes daily adds up to roughly 2.5 hours per sprint, on top of the general Agile standup testers already attend.
Small QA teams with minimal task overlap rarely benefit from a separate daily meeting.
Board-focused standups outperform the classic three-question format for most testing teams, since discussion follows actual work items rather than individual reports.
Situational standups around a specific blocker deliver more value than permanent daily meetings when a bottleneck spans multiple departments.

Below: how to run a QA standup that earns its place in the calendar, and when to replace it with something else. 👇

Why would you need testing team standups?

Here are the main reasons to hold a dedicated test team standup:

Daily standups make it easier to keep a horizontal hierarchy. For a new team member, it can be daunting to ask or keep asking for advice from senior colleagues. After all, they probably have their important things to do while you’re asking things that would seem basic to them. There will definitely be some anxiety that could affect the tester’s work and would certainly affect their mood.

The format of standups, however, puts everyone in the same position. All members of the team share what they did yesterday and what is their plan for today. People mention setbacks and take the opportunity for a quick question to a colleague. You get to hear fellow employees give a status update toward a common goal — not see a boss request a report from their subordinates.
Public status updates boost QA creativity. Software testing requires both an analytical foundation and a keen mind to tackle issues. Just speaking about a bug that you’re struggling to pinpoint can give you a new perspective. The input of colleagues during or after the meeting could help you where documentation or internet won’t. Facilitate collaboration of ingenious testers, as that’s how you build an effective QA team.
Standups provide a sense of progression. The regular Agile cycle of two weeks is a long time to see the fruits of your labor. There is one more pitfall: some features take longer than a sprint, which means there absolutely will be dull(er) releases. Verifying a bug fix for a minor issue can feel like an inconsequential work time.
On the other hand, daily standups start at how things were yesterday, continue with where you left them off by evening, and finish with plans for today. In just a couple of minutes, everyone gets to look at three different timeline points of their workload. That feels like progress even when there is actually very little progress.

The perfect test management tool to see progression and enjoy it

Try aqua

Are there any arguments against standups in the QA team?

You won’t find many companies praising their QA standups, and here are a couple of ideas why:

Time and redundancy are the main reasons why you may not want to hold QA-exclusive standups. Even just 15 or 20 minutes is a noticeable chunk of an 8-hour workday. That is at least 2.5 hours per sprint that could have been spent on “actual work” instead — and you’re attending the regular standup for the Agile team anyway!

Redundancy is a case-by-case matter. The time concern, however, can be addressed with a different approach to QA planning. Our advice: don’t fill everyone’s calendar with 7.5 hours of tasks per day.

Estimate tickets realistically, leaving breathing room for standups and key follow-up discussions. Teams that build in this 15-20% buffer time avoid the bottlenecks that kill momentum – and you’ll notice your delivery becomes more predictable. The most successful Agile teams don’t view coordination as “extra” work but as essential glue that holds everything together.
Testing standups miss the point of Agile. One of its key benefits is putting everyone in the same boat to improve communication across the deck. In that sense, QA-exclusive meetings are just a form of addressing everyday routine rather than a genuine Agile standup.
QA standups can be excessive. Testing teams are often small, and that commonly means little interaction between testers. If your job seldom overlaps with that other testers do, this meme may very well apply.

Modern Standup Formats for QA Teams

Agile standups have moved way beyond just answering those three classic questions. Many QA teams now get better results by ‘walking the board’, which means focusing conversations on actual work items in progress and letting testers speak directly about what they’re testing or where they’re stuck. Pull up a Jira or Azure DevOps board during the meeting and you’ll immediately spot testing bottlenecks that need attention.

For teams split between office and remote, mixing real-time video standups with chat updates works brilliantly. Just make sure blockers stand out so they get tackled fast. The most effective teams use these 5-10 minute sessions as quick alignment tools, not detailed status reports. They highlight urgent issues, sync priorities, and – here’s the key part – immediately pull relevant people aside afterward to solve problems rather than wasting everyone’s time. Start by experimenting with board-focused standups for a week — you’ll likely see coordination issues drop by half.

How to Run an Effective QA Standup

A standup meeting in QA teams works when the format matches what testers actually need to coordinate. Here is a sequence that holds up across team sizes.

Set a fixed time and stick to it. Mid-morning suits most distributed teams, giving overlapping hours across time zones while leaving the early hours free for focused work. Moving the slot around trains people to treat attendance as optional.
Open with the board, not with people. Pull up your Jira or Azure DevOps board and walk items right to left, starting with what is closest to done. Discussion follows the work rather than the org chart, and blocked items surface immediately because they visibly sit in one column too long.
Cap each contribution at 60 seconds. Testers state what moved, what they are picking up, and whether anything blocks them. Detail belongs in the ticket, not in the meeting.
Flag blockers explicitly, then move on. Whoever raises a blocker names the person or team who can resolve it. No solving happens during the standup itself.
Close with a parking lot. List the side conversations that came up, name who joins each one, and end the meeting. Two people resolving a schema question do not need the other six listening.
Run the follow-ups immediately. Parking lot conversations happen in the ten minutes after the standup while context is fresh. Scheduling them for later in the week defeats the purpose of daily coordination.
Review the format monthly. Ask whether the meeting still helps. Formats that worked for a team of eight often stop working at fifteen, and nobody raises it unless asked directly.

You’re not wrong to question this. Daily standups can work, but only when there’s a very clear plan and tight facilitation. Once they start drifting into problem-solving and long explanations, they stop being updates and just become another meeting that eats time.

Emergency-Number4738 Posted in Reddit

A better way to promote communication

Whether a permanent standup meeting in QA teams fits your setup or not, the underlying goal remains the same: faster blocker resolution across the people who can actually unblock each other. We could, however, all benefit from reaching the eluding goal of better communication. Why not start with daily standups for blocker-resolving squads?

Late in 2022, we decided to upgrade all fonts across the website for our aqua testing tool. This seemed like an easily scalable task: pick the font, choose letter sizes, and apply the new font to all website pages. Alas, like most simple things in life, this got complicated.

After some trial and error, we realised that all pages will need to be redesigned with the new fonts in mind. That also meant a lot of manual effort for the development team to reimplement the new pages. The worst part is we couldn’t continue to expand the website until the font endeavour was completed. Otherwise, any new page would have to be implemented and then upgraded in a very short time span.

All these unpleasant discoveries created a whole new scope for the kind of overhaul that most team members haven’t experienced. There is a lot of somewhat new work that blocks any other work. Regular communication is not made for Design, Marketing, Development, and QA tackling a colossal effort of redoing the entire website.

So, we started to hold daily meetings for this now-painstaking effort of updating fonts across the website. These meetings encouraged regular status updates but more importantly helped address blockers very quickly. Here are the things that we achieved with these meetings:

Develop the task-specific format for the Design→Development page handover
Find a way to isolate the font update effort from the implementation of new pages
Optimise the interaction with QA to quickly validate pages with upgraded fonts

These situational standups allowed us to drastically reduce lead time for a task that got out of hand. We have now finished the fonts update and are still on track for a few exciting feature launches.

QA Standup Alternatives: When a Daily Meeting Isn't Needed

Not every testing team needs a daily meeting. When task overlap is low or the team is small, these formats deliver coordination at a lower time cost.

Async written standups. Testers post their update in a dedicated Slack or Teams channel before a set cutoff time. This suits distributed teams across wide time zones and gives a searchable record of who worked on what. The trade-off: blockers get resolved more slowly without a live conversation.
Twice-weekly standups. Two sessions per week instead of five cuts the time cost by 60% while preserving live discussion. This fits teams where individual testers own separate modules and rarely need daily coordination.
Blocker-triggered standups. No fixed schedule. Anyone can call a fifteen-minute session when something blocks their work. Teams that use this format well tend to hold two or three sessions weekly, each one addressing a concrete problem.
Board-driven coordination. No meeting at all. The team relies on a shared board with clear column definitions and an agreement that blocked items get flagged within an hour of becoming blocked. This requires discipline and a well-maintained tool, but removes the calendar burden entirely.
Pair check-ins. Testers pair up and check in with each other rather than the whole team. This works for teams of ten or more where a full-group standup exceeds the useful time limit.

Whichever format you pick, run it for at least three sprints before evaluating. Coordination changes take time to show up in delivery metrics.

aqua cloud syncs bidirectionally with Jira and Azure DevOps, keeping your dashboard updated

Try aqua for free

Common Pitfalls and How to Avoid Them

Two failure modes account for most abandoned QA standups, and both develop gradually enough that teams rarely notice until attendance drops. Watch out for the meeting becoming just a boring status report or – even worse – turning into a top-down assignment session. That kills team spirit and defeats the whole purpose.

Keep standups sharp and time-boxed (15 minutes max). Make them team-driven where folks feel comfortable calling out blockers. If you notice people checking their phones or mentally checking out, that’s a red flag your standup needs fixing.

One practical tip: try the 3-question format – What did you do? What will you do? Any blockers? When side discussions pop up, say ‘Let’s take that offline’ and schedule a quick 5-minute chat right after with just the relevant people. Teams that stay focused on their sprint goals – not just activities – tend to deliver much better results.

QA Standup Checklist and Best Practices

Check	Why it matters
Meeting ends within 15 minutes	Longer sessions turn into status reports and attendance drops
Every attendee speaks	Silent participants signal the meeting does not concern them
Blockers named with an owner	Unassigned blockers stay unresolved until someone notices again
Board visible during the meeting	Discussion anchored to real work items, not recollection
No problem-solving in the room	Detailed debugging wastes the time of everyone not involved
Parking lot conversations happen same day	Delayed follow-ups lose the context that made the meeting useful
Same time daily	Variable scheduling makes attendance feel optional
Format reviewed monthly	Team size and workload change, and formats stop fitting

Additional practices worth adopting:

Keep the meeting standing where physically possible. The format exists partly because standing discourages long contributions.
Rotate who facilitates. A single permanent facilitator gradually turns the meeting into a report to that person.
Track how many blockers get resolved within 24 hours of being raised. This single number tells you whether the standup is doing its job better than attendance figures do.
Skip the standup when the whole team is heads-down on independent work. A cancelled meeting with a clear reason costs nothing. A held meeting with nothing to coordinate costs the team fifteen minutes and some goodwill.

Conclusion

Daily standups in QA have a variety of benefits as long as they fit your team. They work best for larger QA teams, especially with fewer senior employees and new people coming in. If you are experiencing a major bottleneck that involves QA, cross-team daily standups will be a better solution.

Advanced all-in-one ALM for all IT-related teams

Try aqua for free

On this page:

Speed up your releases x2 with aqua

Start for free

FAQ

What are stand-ups for agile teams?

Standups are daily meetings of Agile team members. Everyone briefly shares their progress, raises any blockers, and communicates the plan for the day.

What is the purpose of standups?

Standup meetings help Agile teams spot and address bottlenecks in a matter of hours. The straightforward value of getting a status update helps too, especially for teams on short release cycles.

What do you say in a stand-up meeting as a tester?

Ideally, you should share your progress in an encouraging and/or actionable way. If you are struggling to isolate an issue, ask the team to share their thoughts after the meeting. If you need a dev to get onto a bug fix for an issue that you discovered, give them a nudge. If you have any context or pointers for other team members, do share these.

How long should a QA daily standup last?

Fifteen minutes maximum, and most teams of five to eight testers finish in under ten. Anything longer indicates the meeting has drifted into problem-solving, which belongs in follow-up conversations with only the relevant people.

Should QA teams have a separate daily standup?

It depends on team size and task overlap. Larger teams with junior members benefit from a dedicated session. Small teams whose members work on separate modules usually get more value from the general Agile standup alone.

What should be discussed in a QA standup?

Progress on current test items, what each tester picks up next, and any blockers with a named owner. Detailed defect analysis, tooling debates, and test design discussions belong in separate sessions after the standup ends.