I am about to start managing a team of testers within a company. Each tester is on a different team, one tester per team. For example, one tester is on the database team, another on the software support team, etc. Since each of these development team is effectively a silo I want to begin holding a daily scrum for the testing team. This is mainly for two reasons:

  1. Communication - There is little cross-team interaction. Having communication within the test team will help us all to spot potential issues across the whole development department and communicate them to the team leaders
  2. Support - It can be lonely being the only tester on the team. I want each tester to know that they are part of a team of testers with all the support that entails.

With the above in mind, should I be looking to conduct my scrum with the testers differently from a normal scrum? In other words, should they be conveying anything more than the usual "yesterday, today, blocking" pieces of information?

  • Based on the comments from Joe and Phil, I thought I would clarify that I am using the word scrum very loosely to indicate a daily standup meeting.
    – SheyMouse
    Jan 4, 2013 at 15:18
  • I really dislike the thought of imposing more than one "daily standup meeting" on anyone. If your testers are already involved in one "scrum", than I'd avoid adding another. Even quick standup meetings can start to suck up all your time... Jan 4, 2013 at 16:01
  • You make a really good point @JoeStrazzere. I hope my comment on your original answer covers that. I am now leaning toward a weekly status meeting. I have worked here for 6 months under the original manager and found there were issues on one team which may have been solved by a regular meeting between all of the testers.
    – SheyMouse
    Jan 4, 2013 at 16:58

3 Answers 3


What value is "yesterday, today, blocking" to this team of testers?

Presumably, they have similar scrums where they present the same information to the functional team they are assigned to. So you may be asking them to repeat what they have just said, or will soon say.

Perhaps you instead want to focus your meeting on "what is important for other testers to hear". Perhaps issues on one team are relevant to another. Perhaps delays on the database team will impact the support team, etc.

I'm not sure what makes this meeting a "scrum" in your company. But for all meetings, the organizer should consider

  • Should we meet at all?
  • What value do I want the participants to receive from this meeting?
  • Is this the most effective/efficient way to deliver this value?

We do weekly team meetings to discuss the status and cross-team impact. And we do bi-weekly learning sessions to discuss tips, tricks, and the QA profession in general. Finally, I do weekly one-on-one meetings with each of the individuals to focus on their specific needs.

  • Nice answer. The meeting strategy reinforces being "part of a team of testers with all the support that entails."
    – user246
    Jan 4, 2013 at 14:08
  • I agree @user246. This is a nice strategy. I think that a weekly meeting may prove more productive in the long run. I also like the idea of learning sessions, although I think bi-weekly may be too frequent for where I am working.
    – SheyMouse
    Jan 4, 2013 at 15:14

Even though an answer was already accepted I felt to offer another perspective:

You should not run a scrum for the testers only.

Effective scrum teams rely on their ability to self govern and self organize. So each team will handle things in their own way. If a tester has an issue, he/she should bring it to the scrum master and work it out in the team. If they cannot solve it, then it goes to the scrum of scrums where the appropriate resources are allocated. In my opinion, a strong team dynamic is the most important part of a successful scrum and that needs to be figured out by the team itself, not governed to them. Having a sidebar scrum meeting could create problems. Things could be brought up in one and not the other, or things being repeated twice and having two separate resources trying to solve the same thing. At worst, this could push the testers further away from the rest of their own scrum team.

I think the thing you are looking to organize is a community of practice. I created ours and it has been extremely useful. We use it to stay connected with other testers, share cool testing ideas, and determine testing standards. For more info on creating one, I found this article useful.


Given that a scrum meeting should be really quick, how much support will this actually give the testers! Why are you calling it a scrum, can't it just be a meeting? Also, if you are 'managing' the testers then it seems to more of a meeting than a self-organized scrum... Not saying your idea is wrong, not sure that calling it a scrum is the best terminology

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.