Chris Burns / Technology / September 30th, 2014

What Does QA Do on the First Day of a Sprint?

Have you ever wondered what it would be like to have a full-time QA person on your agile team? If so, you’ve probably immediately wondered what that person would do on the first day of the sprint. Most likely, you thought they’d be doing something like this:

I like to fight for as many QA resources as I can get, so this has become a frequent topic of conversation around the Gainesville office. But last week I was at a technology meetup, and someone asked me, “How can you have a full-time QA person as part of your scrum team? What do they do in the first part of the sprint?”

Clearly, I’m not the only one asking how development teams can make sure their QA resources are used to maximum potential.

It is a really good question, and I asked my Scrum trainer, Tom Mellor, how to keep the QA members of my team busy on the first day of the sprint. He looked at me with a blank stare. You know the one: mouth slightly agape that comes with the unsaid, “Son, are you stupid or just plain dumb?”

I choose to believe it wasn’t the dumbest question he’s ever heard, but after he composed himself he responded with another simple question.

“How can it be the first day of a sprint and one of your team members is already out of work?”

Any rational person, such as myself, would respond, “In the first 10 seconds of any sprint, there’s no way that any stories have already been completed and gone to QA, so the QA person wouldn’t be out of work, but he or she also wouldn’t have received any work yet either.” Right?  Seemed pretty logical to me.

Not how QA starts each sprint.

That’s totally valid, but it is missing an enormous point.  We’re talking about Scrum! We are fortunate to have the Scrum guide to help us navigate these questions, and it’s something that we all review on a regular basis. [Editor’s note: No, we don’t. You nerd.] But just in case you’ve been a little distracted lately, let’s take a look together. These excerpts are direct copy/paste out of the Scrum guide. I’m not making this up.

Scrum recognizes no titles for Development Team members other than Developer,
regardless of the work being performed by the person; there are no exceptions to this rule. – The Scrum Guide
Just for simplicity’s sake, I’ll enumerate all of the allowed titles for team members here:
  1. Developer

Notice how exhaustive the list is? Was QA on it?  So why do you have a designated QA person in the first place? Everyone is a developer, and they contribute to the development of the project. Simple.

Scrum recognizes no sub-teams in the Development Team, regardless of particular domains that need to be addressed like testing or business analysis; there are no exceptions to this rule. – The Scrum Guide

If the first point wasn’t obvious enough, this explicitly states that there are no sub teams “like testing”… which means QA. But what if your QA team is a highly-trained bug-finding force. Too bad, “no exceptions” (see what I did there?).

Now that we are all on the same page, you’re probably thinking, “That’s not realistic,” or “We can’t do that in my organization.”  I’m here to tell you that you both can and should, and later I’ll give you some practical advice to make it happen. But first, another word from the Scrum Guide…


Individual Development Team members may have specialized skills and areas of focus, but accountability belongs to the Development Team as a whole. – The Scrum Guide

Your team probably consists of people who specialize in making pretty things and others who can write awesome queries.  I’ll refer to them as “experts.” All of the members in your team are an expert at something, but that doesn’t mean it’s the only thing they can do. Your artist might never write a complex join statement  and your DBA may never design a button, but there is always a way to pitch in on any story. Always. Even if it’s just sitting side by side to talk through the problem (pair programming anyone?). They might even learn some new valuable skills.

We talked last week about developers growing their QA skills, so why can’t the reverse apply to your QA analyst? There are no special passes here. You probably have a QA expert in your organization, but if a lot of stories need QA, everyone else on the team pitches in, right? Well, they should! Not just the QA experts; every member of the team is responsible for every story at every step towards completion. Even the QA step (Oh, yes I did).

The goal is to drive everything to Done. A person may be 10x slower, but if they have free time, they need to add their 10% effectiveness and improve their skills. “That’s not my job” doesn’t exist in a Scrum team.

Practical Application

This is fine in theory, but how can you really implement this? Even with politics and egos out of the mix, the solution isn’t always obvious. So here are my tips to help your QA expert deliver value from the first minute of the sprint:

  • Have stories to create automated tests & load tests. They are important; train your PO and get it in the backlog.
  • Make sure all stories are really small. My team typically has stories ready for QA on the same day as sprint planning.
    • If a large story takes an entire sprint to complete, how on earth will that get QA’d and fixed before closeout? It won’t, and it needs to pass QA to be shown at closeout. So break it up. And then break it up some more.
  • Encourage your QA person to learn new skills to help move stories to QA. Options include:
    • Learn to program
    • Do some design work
    • Perform some user tests
    • Server setup and management
    • Give shoulder rubs

Scrum teams seem to be really great at making everyone on the team an equal… as long as we don’t talk about QA. They either have a “QA Person” or, even worse, they are in a completely separate QA department. Since your definition of Done should include passing QA (please say it does) and you shouldn’t be showing anything at your closeout without QA, it’s reasonable to say that if you have a separate QA team, you’re just doing it all wrong.

But in terms of QA, remember that you don’t have a QA person any longer. You have a person who specialized in QA but has numerous other talents to pitch in on day 1. My QA expert can write HTML, is learning javascript, and can hit a mean tennis serve. Tell me what yours can do in the comments below.

Image credit: Bert van Dijk
like what you've read give us a shout

  • Trish Trout

    Nicely stated….coming from a member of a team who focuses on QA! Great info!

    • Christopher Burns

      Love it! So as a QA focused person, what sorts of things appeal to you as something you can contribute on day 1?

  • Katie Griggs

    Awesome article, Chris. I’m not gonna let my QA-focused Developers off the hook now!

    • Christopher Burns

      Nice! Keep that fella busy…

  • Peter Brownstein

    I love this article. Favorite one thus far (sorry to anyone I may be offending). I 100% agree with the message in this article, and there is so much QA can do each day of each sprint.

    Note to editor: we do read and reference the scrum guide frequently, and I am ok with that.

    • Christopher Burns

      You like this even more than my squirrel burger one? Thanks Peter 🙂

      • Peter Brownstein

        That is correct. Sorry buddy.

    • mikecush

      Just keeping you on your toes, Peter.

      • Peter Brownstein

        Good point. That is a great way to see if I actually read the article or just looked at the title and skimmed the article. I see what you did there. I wonder what other easter eggs you have left for us in the past…

      • Christopher Burns

        And he’s indirectly calling you a nerd… but I think we’re all nerds about something

  • Sydney Tucker

    Great article. I found it engaging as I found your points relevant to my personal experience. I look forward to reading more from you.

    • Christopher Burns

      Thank you, I appreciate the feedback Sydney! I’ve got some more articles in the works.

  • Ernesto EssayBeats.c

    I am a newly promoted QA analyst at my job and the director of software came up with a great way to keep me busy on my day to day routine.

    I am not only the QA analyst, but also Product Operations Lead. I check the status of the software releases daily, ensure that nothing is standing out as a sign of “breakage” of any sort, and also deploy the software updates with daily monitoring as well.

    This alone fills the “empty space” gaps with dozens of tasks that can provide good insight to what is needed out in the field.

    Just an FYI.

    • Christopher Burns

      Those are some awesome things to do help the team Ernesto and a different direction than I was initially thinking about… thanks for the new ideas! And glad to hear that you’re successfully filling in those gaps and giving your QA department a good name. Keep it up!

      • Ernesto EssayBeats.c

        We’re a small shop so our lean company mentality is what allowed for some creative thinking. I am the only QA person at the moment so I brainstormed with my 2 bosses as to how we can change my title but effectively keep me as involved as I have been.

        I’m also slightly filling in as a bit of a SCRUM master since I’m awaiting features to QA, I am seen as the first point of contact to identify blockers and root cause for potential deadline delays and communicate them as early as possible to the Director of Software Engineering.

        I’m not the only point of contact for project managing but definitely the first to see red flags. This is another way I fill in the gaps.

        It’s a very busy work day I have but extremely fun and yes, one that I am proud of without a doubt. 🙂

        If you ever have any questions, feel free to ask me.

  • Lincoln Anderson

    Recently we’ve been able to unleash our QA Analyst on some automated regression testing, and it’s been amazing to watch. I don’t know how we’d be able to detect the issues he’s found without really investing in his time. Also, he’s shown me how to use quite a few testing tools that help me get things closer to done faster. This is still a great post that will continue to be proven out as time passes.

  • Kamran Khan

    I loved the way you’ve described, in fact, I’ve take some notes from this page. I will use this in my up coming senior level positioning in a new company I’m joining next month.

    • Christopher Burns

      Awesome! Let us know how it goes.

  • Michael Vieira

    What about what does your Developers with a programmer expertise do at the end of a sprint?

  • Christoph

    I really enjoyed this article – great writeup of a lot of issues/statements I’ve seen. Thanks!

  • bongo

    Few other things you can do – write test cases, create test data you will need to run your tests, and also automate your testing. If you are working on API automation ask your developers to deliver you the API on that first day even if it is returning a mock object. If you are working on UI app ask them to deliver the UI that is not hooked up to anything in the backend. Write automation libraries that you can use for your automation of those stories, or refactor some other automation code you have. I have worked on teams where our automation was done before development and even though people called it TDD I preferred to call it automation in parallel with development. The tests would basically fail until the code was developed, and sometimes even developers used it to test before they checked in their code.

    • Christopher Burns

      Amen! thanks for the additional ideas.

  • David Murphy

    My team implemented automated acceptance as well as unit testing, plus performance testing. QA works with a BA / Product Owner on initial backlog grooming and user stories, brings a QA perspective to acceptance testing. Defines tests in cucumber style scripts (we actual use Gauge but the principle is the same) and the devs do the actual translation to running code. QA reviews results, does exploratory testing and generally helps improve the overall quality output. At the other end of the spectrum in the last day or two the divs run out of work except for defect fixing. So we get them to run some tests and generally support the QA. QA also started to learn some code (she had done Java code as art of her CS degree, but hardly touched it since, so she was keen to improve her skills. She was also able to sit with devs and ell them overcome defects by being a second pair of eyes and ears.

    Breaking down the barriers was difficult at first but gradually the team evolved to manage this.

  • Lou Bichard

    Nice article Christopher. I’ve always found it hard juggling the idea of people having roles. I’m not sure if you’re aware, but this is a problem defined by Peter Senge as a “learning disability”.

    > I am my position” – with this disability, individual units in the organization focus too closely on their own positions and responsibilities, thus missing out on bigger pictures and inter-unity.

    I think you’d also appreciate the HBR article “Six Myths of Product Development” where the author discusses the fallacy of high utilization of resources. I think that applies too to the topic.

    I think on paper, your ideas make sense, having everyone chip in on different areas to help the team. I’ve often found a few obstacles.

    The recruitment market: The way we hire means we hire for specific roles, meaning we get people with deep expertise in a single area. They are also often conscious to not dilute their skill set. Appreciation of other roles is often a good thing, but I find if you dilute roles too much, people become anxious of what it means for their career.

    Unified vision: This model works if you can get people to consider the team goal more important than their personal need to fulfil their role (something I find is much easier to say than do).

  • Daniel Marcantel

    This is not that hard. If your are dedicated to quality and you should be a QA resource should already be engaged by understanding the stories, getting test plansscriptsautomation environments ready. There is a lot to do before they get their 1st piece of code.

  • Corey Condardo

    “Give Shoudler Rubs” is further minimizing the effect a QA resource can have on a team beyond their ability to test. I know it’s a joke but it’s perpetuating the problem.