Having a separate Sprint for development and QA

In general, I'm not opposed to a Sprint resulting to a hand-off to something that isn't a release. A good example of this kind of situation would be in an environment where independent verification and/or validation is required. However, there are really very few (relatively speaking) environments that require independent verification and/or validation, and even then not all work needs to undergo this process.

For most cases, I'd say that yes, splitting development and QA is anti-Scrum because it is both anti-agile and anti-lean. You are introducing artificial barriers or silos in your value stream. These hand-offs are waste that slows down development, forces communication paths into certain structures, and slows down delivery of value to downstream customers.

Here are some questions to consider:

• Why is all of the work coming at the end of the Sprint? Why is work not being delivered incrementally?
• How can QA-related activities be moved up-stream? Can QA begin to define and implement blackbox tests based on your Product Backlog Items earlier? Can the developers integrate test design and implementation into their work?
• Why do you have a separate QA? Is there a reason? Is this reason valid?

The idea behind having a Sprint is to produce a "Done" increment. Having said that, would you consider the functionality being developed as use-able at the end of your Sprint i.e. without appropriate Quality Assurance?

What would you do if you were given the option to change something with respect to this scenario? What do you think is perhaps the cause?

In general, I'm not opposed to a Sprint resulting to a hand-off to something that isn't a release. A good example of this kind of situation would be in an environment where independent verification and/or validation is required. 

@Thomas Owens, I was once in a position where the management forced this thought, considered it okay and called it Scrum. If we have a Development Sprint, hand-off that work to a QA Sprint, then, how is that different from Waterfall?

@Thomas Owens, I was once in a position where the management forced this thought, considered it okay and called it Scrum. If we have a Development Sprint, hand-off that work to a QA Sprint, then, how is that different from Waterfall?

Because the work should still be Done. When facing regulatory compliance in areas that require some or all of the work to be independently verified or validated, it is not possible for the Scrum Team to perform the work with independence - they are too close to the work. The external group that receives the hand-off should be responsible for compliance related 'paperwork' - if they are finding issues (especially those that would prevent the release of the software) rather than checking compliance related boxes and providing feedback, the Scrum Team did not meet its objectives.

@Thomas makes a good point when producing things for regulated industries.  I worked for a company that was subject to US Security Exchange Commission audits.  We did a variation of agile but not Scrum.  It was mostly a home grown process that used time-boxed periods with reviews at the end.  We did split Development and QA and it was not uncommon for work to span time-boxes. But again, we weren't doing Scrum.

@SteveB also makes a good point.  Doing the split could very well be seen as an implementation of waterfall in most cases. And having something that isn't tested really doesn't seem "done" to me.  Is it potentially releasable at that point? 

Scrum says that the increment produced in a Sprint is potentially releasable. Does your organization feel that something that has not undergone full testing is potentially releasable? I really hope not and since you have a separate QA it doesn't seem like your organization does feel that way.

I am also going to point towards focus.  If Developers spend 2 weeks building something and then QA tests for 2 weeks, what are the Developers doing during the QA Sprint?  I'm going to venture that they are going to be writing new code.  If QA finds an issue, does the Development Team stop working on the new code to fix the issue or does it go into the Product Backlog to be fixed at a future point?  Either method is going to result in delays delivering value to the stakeholders.  There will be significant context switching all the time. Why not make the stories smaller so that they can be coded and tested during a Sprint?  You do not have to deliver a completed feature every Sprint but you should deliver an workable, potentially releasable increment of that feature. 

My opinion is that you split the work like you suggested if there are very good reasons.  The reason you mentioned is not a good reason at all. It is a symptom of a team misunderstanding the benefit of agile and of Scrum. If your organization is truly committed to doing Scrum, you need to work the team to help them understand how their actions are not supporting Scrum. 

Our QA is having this problem of nothing having anything to do while the developers are coding and the he get suddenly flooded with work 3 days to the end of the Sprint which he struggles to finish.

What is being done to limit work in progress, so items are completed earlier and more often?

So we are looking at Splitting the Sprint, having one sprint to develop and one sprint to test. Is this anti-Scrum?

As per me yes its Anti Scrum which can increase waste as mentioned by @Daniel in following sprints.

Why not try to use QA as an activity to prevent bugs than reporting bugs? What do you think about TDD or BDD ? Why not involve the tester during the development phase itself and find the problems early to save time later?