When to close a Sprint, before or after QA

[Nichole Latessa]

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-

[Steve Schiff]

My view is that stories are not completed until testing is complete, if you have testers working with developers continuously. One way of doing this is to have developers resolve stories that they have completed, and create a "pending QA column" that the resolved stories are moved to. If QA finds that the story has an issue, they can comment and put back into pending development. Once QA clears a story, they mark it closed. 

Resolved but untested stories are carried over to the next sprint. 

In this model, development and QA are both on the hook for velocity. 

[Shannon McRae]

I definitely agree with keeping your sprint open until AFTER the QA work has been completed.  One argument I have used in the past for this is, what if the QA work finds a bug or a problem that needs to be reworked? if the story is still open you can do it as part of that original story.  Make an additional subtask for the issue found by QA and do it immediately.  If an issue is found after the sprint and story are already closed, it means that a new bug report needs to be filed and scheduled and pointed for another sprint.  In the case of my current company, that also means a 2nd deploy schedule which takes extra time.  The sooner you find an issue in the developement lifecycle, the better.  It saves time and money.  I hope that helps!

[Jindřich Löffler]

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)

[Shannon McRae]

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. 

[Nic Brough -Adaptavist-]

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.