Why having a separate week of QA in your sprint is not agile
Have you ever asked an agile team their sprint length and they say, but a week of it is for QA? I’ve heard this often and it always makes me raise an eyebrow.
It’s not my responsibility
To me it means the team is more focused on process than it is on outcomes or people. Whenever there are dividing functional responsibilities you run the risk of getting into the, “it’s not my responsibility” problem. This is a phrase I don’t want to hear from my teams. Everyone is responsible for helping deliver the sprint work at all times.
When you have a week of QA, the developer believes they are done after their weeks of development, however that ticket is in limbo and we aren’t sure if it’s actually done. And let’s face it, there is usually at least one bug. With a week of QA you run a higher risk of work not getting completed within the sprint.
Many teams still have separate QA functions, and that’s okay, we can work with that. There are a few things that need to change with the development and QA teams’ dynamics to set them up for success if they are going to have separate functions.
A sprint is a time box for focusing on a subset of work that we can then get feedback on at the end of the sprint in our review. Yes, you can do a week of QA, but that’s not agile; it’s closer to mini-waterfall. We want feedback throughout the development process as well, not just at the end of the sprint.
Include QA in the very beginning
What’s the trick to making a QA function work in an agile process? Including them from the very beginning of the development process.
They should be there in backlog grooming to help with acceptance criteria, in sprint planning to help with estimating how long it will take to get the ticket to the definition of done, and during the sprint to offer feedback to development when they have questions. This can be difficult when you don’t have dedicated QA team members embedded on the team but have conversations to see if you can have a few members that work more closely, and consistently, with your development team.
QA should not be seeing a ticket for the first time when they are about to work on it. If it is the first instance they are seeing it they are going to need to take time to understand the ticket as well as reach out to the development team, product owner, or UX to ask clarifying questions, which takes up their time and others. When QA finds a bug, development is going to have to go back to resolve the issue as well. Many of these bugs could have been resolved or prevented in early discussions.
I am not here to optimize your development time, but to optimize the overall process
Leaving QA until the end and as a separate function actually causes the process as a whole to take longer. It’s very difficult for development to comprehend that I’m not here to optimize their development time, but to optimize their overall process time. I do care how their time is used. They shouldn’t have to explain things to QA at the end of a sprint over and over again or fix bugs that could have been caught or resolved early on.
If development teams are constantly working with QA from the beginning when the ticket is initially discussed, checking in with QA during development, and working closely with them to resolve bugs, they will find that even though it seems like more work up front, it actually goes faster because they are sharing knowledge and understanding throughout the whole development process.
Sometimes, even if all members of the team function great together, there are times QA could have more work than they can handle. What happens when it comes down to the end and all work is “dev” complete for the sprint, but everything is in QA? I tell developers to help QA out if needed before starting anything new. That look on their face is always priceless.
Your team won’t reach their full potential
To summarize my views, QA week at the end of the sprint is just mini-waterfall. Even when development teams say they involve QA, if they are passing tickets back and forth with minimal collaboration and disregarding work that is no longer on their radar, they are right back to a waterfall model. On this smaller scale, the repercussions are minimal, even hard to notice, but your team still won’t reach their full potential.