Skip to main content

Should we have separate development & testing sprint in Scrum

Last post 10:17 pm November 14, 2022 by Daniel Wilhite
2 replies
03:15 pm November 14, 2022

My team has been raising this issue again and again that they do not get sufficient time to test as in 2 weeks sprint PBI is delivered on 5th day and QA has to complete the testing in remaining days. There are chances that they could find bug at last moment which would eventually lead to spill over.

So they wanted to have development done in Sprint 1 & testing in Sprint 2 and so on which will ease out the pressure. 

Is this an ideal scenario? 


09:48 pm November 14, 2022

My team has been raising this issue again and again that they do not get sufficient time to test as in 2 weeks sprint PBI is delivered on 5th day and QA has to complete the testing in remaining days. There are chances that they could find bug at last moment which would eventually lead to spill over.

Why doesn't the team reduce its work in progress limits, so Product Backlog items are available for test early and often? Focus is essential to Scrum.

So they wanted to have development done in Sprint 1 & testing in Sprint 2 and so on which will ease out the pressure. 

The Scrum Guide says "Sprints are the heartbeat of Scrum, where ideas are turned into value." The proposal being made would result in two fake Sprints, neither of which would succeed in these terms. It might feel as if pressure is being eased out because it would cover the problem up.


10:17 pm November 14, 2022

If you split the 2 Sprints as you said the next complaints you will hear is that the Developers do not have enough work to do during the Test Sprint and the Testers do not have enough work to do during the Development Sprint. 

That is not fixing the problem you have.  It is trying to hide it.  The problem is that Scrum Team has sub-teams within the Developers.  

The section of the Scrum Guide that explains the Scrum Team opens with this paragraph

The fundamental unit of Scrum is a small team of people, a Scrum Team. The Scrum Team consists of one Scrum Master, one Product Owner, and Developers. Within a Scrum Team, there are no sub-teams or hierarchies. It is a cohesive unit of professionals focused on one objective at a time, the Product Goal.

Developers are defined as 

Developers are the people in the Scrum Team that are committed to creating any aspect of a usable Increment each Sprint.

So, your QA would be considered Developers in the Scrum responsibility definition.  I suggest that you encourage them to investigate better agile testing methods.  I have a 20+ year background in QA.  I find it hard to believe that 5 days of development takes 5 dedicated days to test.  Especially in a Scrum environment.  There should be potential to test things from the first day of the Sprint if you are breaking your Product Backlog into small incremental units of work.  Your description sounds very much like you are doing waterfall process in 2 week increments.  Just saying that your are "doing sprints" does not mean you are being agile in what you do. 


By posting on our forums you are agreeing to our Terms of Use.

Please note that the first and last name from your Scrum.org member profile will be displayed next to any topic or comment you post on the forums. For privacy concerns, we cannot allow you to post email addresses. All user-submitted content on our Forums may be subject to deletion if it is found to be in violation of our Terms of Use. Scrum.org does not endorse user-submitted content or the content of links to any third-party websites.

Terms of Use

Scrum.org may, at its discretion, remove any post that it deems unsuitable for these forums. Unsuitable post content includes, but is not limited to, Scrum.org Professional-level assessment questions and answers, profanity, insults, racism or sexually explicit content. Using our forum as a platform for the marketing and solicitation of products or services is also prohibited. Forum members who post content deemed unsuitable by Scrum.org may have their access revoked at any time, without warning. Scrum.org may, but is not obliged to, monitor submissions.