It seems to be very common when there is a project which is trying to implement SCRUM, and which can never really do it because of the inherent problem which occurs when there is a dedicated QA team.
SCRUM assumes QA happens within the sprint, but, when scrum development team is different from the QA team, it can get really messy.
Since, of course, QA can’t start till development is done. Which means QA usually starts close to the end of the development sprint, and that leas to all sorts of workarounds with each of eventually breaking the SCRUM process:
- There might be 3 weeks sprints with the last week being reserved for the QA. But what is it the developers are supposed to do during that last week?
- QA team may choose to do their work outside of SCRUM; however, if “QA test passed” is part of the definition of done for the dev team, they’ll never be able to close work items within their sprints, and, at the very least, that’s going to render burndown charts useless
The problem here is, usually, that it’s almost impossible to blend traditional QA and development within the same sprint, and, this way or another, we end up with the diagram below if we are trying to complete both development and QA within the sprint:
So what if we treated DEV and QA processes as two different SCRUMs?
That would requires a few adjustments to the definitions, but, I guess, we could think of it this way:
- The dev team would still be responsible for their own testing, and they’d be doing it within dev sprints. This might not be the same level of comprehensive testing a QA team can deliver, but, as far as Dev team is concerned, there would be release-ready candidates after each sprint, it’s just that they’d be released to the QA team first
- QA team would be responsible for comprehensive testing, possibly for adding test automation, etc. They’d be doing it within their own set of sprints, and, by the end of each sprint, they’d have added known issues to the release candidate provided to them by the dev team. That release candidate (with the associated list of known issues) could be made available to the end users
Of course this would assumes some level of communication between two teams, but this is where Azure Devops can really help because:
- Within the same project, we can create multiple teams
- If we choose so, each team will be able to see the same work items
- Each team can have its own set of iterations
And, of course, we can have joint sprint reviews, scrum of scrum meetings, etc.
So, how do we set it up in devops? Here is an example:
For a Scrum project in Azure Devops, create a Dev team and a QA team
There will always be a default project team as well, btw. You can use that one in place of one of the other ones if you want.
Configure project iterations
Notice how DEV and QA sprints are aligned. They don’t have to be
For my example, I’ve set up each team to have access to the default area AND to all sub-areas(sub-areas are included on the screenshot below)
Dev team should have access to the “dev” set of iterations
QA team should have access to the QA set of iterations
With the setup done, I can now go to the sprint boards for the Dev Team (notice team selection at the top), and add a work item to the bord + a task:
There would still be noting on the taskboard for the QA team:
By the end of the sprint, my task #5077 would move to the “done” state on the Dev Team taskboard:
And I (as a developer) could create another task for the QA and put it to the upcoming QA sprint (which is not quite in compliance with SCRUM principles… but QA team can, then, decide to get those items off the upcoming sprint and handle it in the sprint farther away):
Now if I look at the QA sprint taskboard, here is what shows up here:
And there you go: Dev Team will be working on their own set of sprints, yet QA Team will be working on their set of sprints. Each team can plan their work, they don’t depend on each other when closing the sprints, and it’s just that the “release candidate” has to go through a two step process now:
