Project Management Stack Exchange is a question and answer site for project managers. It only takes a minute to sign up.
Sign up to join this community
Why do we need Parallel Sprints? I am trying to understand the use case here. Consider our Use case
We have two developers and two testers on our scrum team
We have four developers joining the team (but they are not dedicated team members)
Our sprint cycle is 2 weeks
Do you recommend parallel sprints for this scenario? The team is thinking to have sprint 1 and sprint 2 (with four developers) start on the same date, but sprint 2 to have 3 weeks cycle to accommodate the testing.
No. Lack of a central coherence violates a core principle of the Scrum framework. Don't do this by choice.
The team is thinking to have sprint 1 and sprint 2 (with four developers) start on the same date, but sprint 2 to have 3 weeks cycle to accommodate the QA testing
Testing post-facto is a well-known agile anti-pattern. This is generally done to avoid dealing with the lack of a cross-functional team upfront. In other words, it's an attempt to bury an organizational dysfunction behind something that sounds agile-ish, like "parallel Sprints."
For Scrum, the rule of thumb is:
One Product ➡️ One Project ➡️ One Team ➡️ One Integrated Increment
Even in scaled agile implementations, you must still have an integrated increment each iteration, even if you have multiple teams. That isn't the case here, though; there's no way to create an integrated increment with teams split along functional lines the way you propose.
A core agile practice is to do test-first development. By integrating your testers and developers into a single team, you ensure that the team as a whole maintains a central coherence (which is required by the Scrum framework). You will also generally increase product quality and reduce technical debt over the life of the project by leveraging collaborative test-first practices.
While there are certainly cases where you can't fix an organizational dysfunction, the job of the Scrum Master is to ensure that:
If you don't do those things, you aren't really following agile principles and best practices. As a result, you are unlikely to reap the benefits that a truly agile implementation would provide.
If management won't allow you to integrate the testers and developers, they are creating project risk. Management always owns business risk, so if they break the process they get to keep both halves.
I'm not certain what is being accomplished with this, but it does feel like it goes against some principles of Scrum.
The Scrum Guide says that "Development Teams are cross-functional, with all the skills as a team necessary to create a product Increment." It doesn't sound like that is what is happening here.
Also, it seems like running separate sprint cadences impedes your ability to create a product increment at the end of each sprint.
I'd answer the question with a question - what's the purpose of the sprint(s) in you context?
Thus, the approach should depend on the value expected to be delivered at the end of each Sprint (parallel or not).
Side note: Based on my experience, when a team is increased by adding new joiners, you don't create a new team. Instead, you onboard the new joiners as part of the current teams (not as active capacity) for training purposes. Once the new members mature and understand how the team works, then the decision of keeping a single team or separated teams is taken.
Agile is a team sport. As first step I would see team building. Team dynamics is very important subject. When you are done with that then it should be team decision how they want to work.
