When to close a Sprint, before or after QA

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-

4 answers

This widget could not be displayed.

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. 

This widget could not be displayed.

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!

This widget could not be displayed.

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.

This widget could not be displayed.

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)

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. 

Suggest an answer

Log in or Sign up to answer
Community showcase
Posted Thursday in United States

Local Atlassian Research Workshop opportunity on Sep. 28th

We're looking for participants for another workshop at Atlassian! We need Jira admins who have interesting custom workflows, issue views, or boards. Think you have a story to sh...

51 views 0 0
View post

Atlassian User Groups

Connect with like-minded Atlassian users at free events near you!

Find a group

Connect with like-minded Atlassian users at free events near you!

Find my local user group

Unfortunately there are no AUG chapters near you at the moment.

Start an AUG

You're one step closer to meeting fellow Atlassian users at your local meet up. Learn more about AUGs

Groups near you