When to close a Sprint, before or after QA

Question

My Scrum Master feels its the best practise to close a Sprint when QA testing is not compete-  she does this for upper managment reporting politics- she will Clone the remaining tickets that are still needing QA sign off and add them to a different project.  I told her I don't agree with this method, we shouldn't be cloning tickets just to  close a sprint so her burn chart numbers look good.  The tickets that have not been signed off for QA, after the sprint cycle is done, should be moved to the next sprint. Has anyone been in this predictment  before, if so how did you solve it?  Is there a way in Jira to have multiple sprints opened for the same project? We do not have our sprints set up to where coding is done in the current sprint, testing in the previous sprint, and analysis in the future sprint, due to aggressive project deadlines.
I was able to convince her to keep the sprint opened (till the sprint cycle ends) till QA finishes their testing, anything that is not complete can be rolled over into the next sprint and all remaining tickets that need to be verified by UAT can be moved/cloned to another project, till we can push them to production-

Shannon McRae · Answer

I would definitely avoid formally splitting your sprints like this.  The testers and the developers should be able to work closely together on a story by story basis through out the entire sprint, not just the first and second half.  When you split it up you're implementing tiny waterfalls.

Jindřich Löffler · Answer

Feature that is not tested should not be considered as a "complete" so it should moved to the next sprint.

For me it seems that time for develop a feature that has to be tested tooks almost whole sprint, so that you can´t make it to be tested to end of sprint.  This happens often in agile testing.

It clould help if you Scrum Master plan development activities (implement features) for the first half of sprint so testes will have second half for testing and developers for fixing bugs and in free time analyze and planning of features (grooming) for the next sprint.  Testers in first part of sprint could prepare tests for upcoming feature implementation and consult testability, preprare test data etc..

So sprints will divide into 2 phases (Test Analysis + Implement features | Testing + Feature analysis, bugfixing)

Nic Brough -Adaptavist- · Answer

For the case you describe, considering QA to be part of the sprint is by far the best option.  Don't clone or move on, your QA should feed back quickly and enable you to deliver rapidly, as it's part of your sprint.

It's not always, there are times when it doesn't work (when QA is completely separated from Dev for example, but that's not a great idea in itself anyway).

As for the details of why, Shannon and Steve have covered everything I wanted to say about it.