Thanks for your comment! I was actually thinking that a given QA team would only be working with a single team of developers. I did not consider sharing the QA team. So it was still, in a sense, a single cross functional team in my scenario. I agree that sharing a group like that is departing rather far from the core idea of what a process like Scrum is trying to do.
I was trying to reconcile two things: a) the need to have a separate testing activity after the developer considers a task completed and b) the fact that in Scrum, it's considered quite important to finish the tasks one commits to in a given sprint. The latter is not going to happen 100% of the time in the real world, but still, the whole philosophy of Scrum is to minimize the distractions so a team can make a commitment and stand by it in each sprint.
If we assume that it's not good enough for only the developers to consider a job done1, then if we keep a single sprint, we'll have work that a developer has completed just at the end of the current sprint going into the next sprint to be checked by QA. At the time, I thought we could mitigate this problem with separate sprints. However, now I think that's a bit of an artificial distinction, and maybe it creates extra structure without a clear benefit.
Probably it's simpler to just have a single sprint and accept that we'll need to carry over several tasks each time into the next sprint for QA. Maybe that makes a case for having a more fluid project structure like Kanban in the first place, where we just don't bother so much with this idea of a single sprint.
1In an ideal world, maybe we can expect the quality of work done by a given developer, or pair of developers in the case of pair programming, to be high enough, that we don't need a separate QA activity at all. I think that in practice, there are a lot of cases where this won't work though, even if we do have high quality being delivered by the development team and they're working hard to thoroughly test their own work first.
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
Thanks for your comment! I was actually thinking that a given QA team would only be working with a single team of developers. I did not consider sharing the QA team. So it was still, in a sense, a single cross functional team in my scenario. I agree that sharing a group like that is departing rather far from the core idea of what a process like Scrum is trying to do.
I was trying to reconcile two things: a) the need to have a separate testing activity after the developer considers a task completed and b) the fact that in Scrum, it's considered quite important to finish the tasks one commits to in a given sprint. The latter is not going to happen 100% of the time in the real world, but still, the whole philosophy of Scrum is to minimize the distractions so a team can make a commitment and stand by it in each sprint.
If we assume that it's not good enough for only the developers to consider a job done1, then if we keep a single sprint, we'll have work that a developer has completed just at the end of the current sprint going into the next sprint to be checked by QA. At the time, I thought we could mitigate this problem with separate sprints. However, now I think that's a bit of an artificial distinction, and maybe it creates extra structure without a clear benefit.
Probably it's simpler to just have a single sprint and accept that we'll need to carry over several tasks each time into the next sprint for QA. Maybe that makes a case for having a more fluid project structure like Kanban in the first place, where we just don't bother so much with this idea of a single sprint.
1In an ideal world, maybe we can expect the quality of work done by a given developer, or pair of developers in the case of pair programming, to be high enough, that we don't need a separate QA activity at all. I think that in practice, there are a lot of cases where this won't work though, even if we do have high quality being delivered by the development team and they're working hard to thoroughly test their own work first.