Why do we need Parallel Sprints? I am trying to understand the use case here. Consider our Use case

  1. We have two developers and two testers on our scrum team

  2. We have four developers joining the team (but they are not dedicated team members)

  3. 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.

  • 2
    QA should be part of each Sprint and included in your Definition of Done.
    – Todd A. Jacobs
    Apr 8, 2019 at 18:58
  • What does the team give as their rationale for this suggestion? Are the 4 new non-full-time developers proposed to be on the "sprint 2" team together, so as not to disrupt the existing 4 person team? Apr 9, 2019 at 1:52
  • Closely related: pm.stackexchange.com/a/26158/4271
    – Todd A. Jacobs
    Apr 10, 2019 at 2:49

4 Answers 4



No. Lack of a central coherence violates a core principle of the Scrum framework. Don't do this by choice.

Sequential Work is Usually Evidence of Organizational Dysfunction

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.

Integrate Your Teams with Test-First Development

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:

  1. the dysfunction is surfaced
  2. acknowledged by the whole Scrum Team
  3. accepted as a business risk by senior management, and
  4. kept visible as an ongoing cost to the project.

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?

  • If you use a Sprint as a way to deliver a specific goal, and both teams can deliver value independently, having separated Sprints is not a problem.
  • If both tickets are dependent between then, why having two different teams?
  • If you use a Sprint as a way of packing up a pile of tickets, why using Sprint at all?

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.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.