It's not the same without you

Join the community to find out what other Atlassian users are discussing, debating and creating.

Atlassian Community Hero Image Collage

When to close a Sprint, before or after QA

Nichole Latessa Jun 14, 2017

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

2 votes
Steve Schiff Jun 14, 2017

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. 

2 votes
Shannon McRae Jun 14, 2017

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 votes
Nic Brough [Adaptavist] Community Leader Jun 14, 2017

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.

0 votes
Jindřich Löffler Aug 28, 2018

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 Aug 28, 2018

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. 

Like Mark Schmick likes this

Suggest an answer

Log in or Sign up to answer
This widget could not be displayed.
This widget could not be displayed.
Community showcase
Posted in Off-topic

Disney Live Action Reboots: Are you for or against?

Happy Friday Everyone! Today marks the international release of Disney's live action version of the animated classic Aladdin. I know that this movie was met with some controversy of over cast...

194 views 21 10
Join discussion

Community Events

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

Find an event

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

Unfortunately there are no Community Events near you at the moment.

Host an event

You're one step closer to meeting fellow Atlassian users at your local event. Learn more about Community Events

Events near you