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-

3 answers

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. 

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!

0 vote

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.

Suggest an answer

Log in or Sign up to answer
How to earn badges on the Atlassian Community

How to earn badges on the Atlassian Community

Badges are a great way to show off community activity, whether you’re a newbie or a Champion.

Learn more
Community showcase
Published Thursday in Jira

5 ways you can make the most of Jira Software and Bitbucket Cloud

As part of the Bitbucket product team I'm always interested in better understanding what kind of impact the use of our tools have on the way you work. In a recent study we conducted of software devel...

76 views 0 5
Read article

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