How to run QA sprints alongside product sprints in the scrum
Tags: Test Automation, Software Testing, Quality Assurance, Agile, Scrum

A couple of years ago when Agile-Scrum was first introduced to me I was so confused about the QA role in a scrum team. For better understanding, I approached the so-called ‘Scrum-trainer’

And his response was this,

“I t’s a crossfunctional team, there are no tester, developer tags in the scrum. Apart from product manager and scrum master, everyone will play the role of scrum member, whose only focus is to develop and release the planned deliverable items of the sprint”.

Sounds simple right? well here is the thing,

After spending 6 scrum years as a QA, the realized reality was far different than this simple definition. In fact, I strongly feel that the QA role was not properly defined in the agile manifesto. A major work style drift that I felt stepping into scrum was, Scrum pushes QA towards delivery, elevates & appreciates faster delivery than the quality of deliverables, which hammers the basic fundamentals of software testing.

Before the era of Agile-scrum, We used to live in our own individual/independent testing teams, we had well-defined strategies and principles to maintain the quality of the product and the freedom to decide the testing timelines but scrum coerced its own strategies on the matured QA process, enforcing us to focus on delivery over quality.

If we travel back in time and look at the Test plan document of any waterfall or v-model project, it liberally dedicates the necessary time for each QA activity without showing favoritism towards delivery.

There are many unattended QA concerns in the scrum but out of them the most paining problem still not been addressed by scrum is, How and when the testing team can work on their delivery independent QA tasks (like Test automation, Non-functional test activities, documentation, etc.,)? because scrum is a never-ending process, sprint after sprint, deadline after the deadline it keeps ongoing and almost all the scrum projects that I have worked so far considers them as QA related or Adhoc tasks but not delivery related or delivery impactful work items.

Let’s consider Test automation, most of the time it’s not enlisted in the product road map, we never see it added to the user story’s definition of done(DOD), but our companies/teams want QA to magically/Adhocly finish the Test automation, not considering it needs time and effort to build solid automation to safeguard the software product.

Test automation is not a task, it’s a project.

My intentions are not to preach scrum as a curse on QA, in fact, EOB features are the value generators for any company, not test automation or miniature QA issues. Honestly, I like scrum, and I’m thankful to it for pulling me out of the rigid, mundane waterfall model to energetic and aggressive software development workstyle.

Here, I’m just trying to shed some light on QA concerns in the scrum and trying to add my experience and advise others on how we can solve them.

So, how to fix this? how can we manage delivery independent QA tasks in agile-scrum? my recommendation is to start and maintain a separate QA Scrum project to manage all your delivery independent QA tasks as an individual scrum team.

what’s the way to create our own QA Scrum project and manage sprints alongside the product development sprints? and how can we squeeze in our sprints within regular product sprint timelines?

Below are the 7 golden steps I followed and been successful in building and managing the QA scrum project

Figure out road map

First and foremost, design a high-level road map that dictates and directs your team to accomplish QA activities in an organized manner.

As a QA team, what we want to achieve and how we would like the improve the QA process/activities that could benefit the company and our team.

What can be QA objectives? well, they can be anything apart from your daily sprint user story related tasks. Usually, Test automation, performance testing, use case documentation, onboarding new resources, offsite training, process improvement tasks, etc.,

As repetitive regression testing is necessary to perform on frequent code release process in agile, make building test automation framework your highest priority in the roadmap.

Better to plan for the next 6 months or next quarter.

Elect a PM & SM

I know it sounds cliche but it’s super important to include the most powerful luxury of the scrum. You can make this optional but it’s nice to have one hand that holds and another hand to pull in any project.

If the team already has a QA lead/manager/engineering manager then he/she would be the best choice for PM role because that person will already have the insight of QA future within the company.

For scrum master, choose someone who is good at organizing and delegation of work items, should have both technical and product knowledge and possess problem-solving skills.

Run a week behind

We always need to remember that our QA sprint execution depends on the speed and space provided by the product sprints.

So, better to make sure our QA sprint timeline does not fall on the exact weeks of our product sprints. Meaning, If the development team is following a biweekly delivery and the current sprint is Week 1–2, then our QA sprint must be planned to happen on week 2–3. This way we can keep out the pressure of finishing things on the same deadline.

Estimate less

Overestimating, this is where our team really screwed up when we first started with QA scrum. Sprint burndown velocity is always dynamic, in delivery bottleneck situations we may not even get time to work on our QA tasks, that’s the reality.

So it’s always better to estimate lesser sprint points and finish than planning more and end up with leftovers. let’s say, we can work on 32 story points in the sprint than go for 24–28 user points.

Simple stand up : measure daily resource bandwidth

Maintain everyday standup among QAE’s, make it simple.

In our current team, we usually do it along with our morning coffee. Our objective is to find how much bandwidth the resources have to work on QA sprint tickets and look for any impediments

· Sharing team member’s planned activities for that day

· Find out who has the bandwidth to work on QA sprint tickets

· Check the status of the ongoing sprint

· Collect impediments

Don’t procrastinate

Starting a QA Scrum project is not enough, we also need to run it effectively. Most of the time we tend to lose focus and try to postpone the tasks, making it a facetious activity. This is bound to happen due to the lack of attention and seriousness we may expect from the rest of the IT team towards the QA project.

The solution to cross this hurdle is to allocate some fixed hours to QA work items every day, make it consistent. It can be an hour each day but we need to show an undiverted focus during this time.

Publish existence

The last but most important task is to keep our IT team aware of the QA Scrum project, grab their attention, demonstrate why delivery independent QA tasks are critical and time taking.

We can do this by sending weekly status updates about the project, doing recursive demo sessions on the automation progress, etc.,