Help with the Sprint field clearing, with a "+1"

lsieben

I'm just starting to try and use JIRA's sprint features, and something happened that makes me think i'm doing something not-the-JIRA-way, not-the-Scrum-way, or both.

I created a sprint, and assigned various stories to it for my team.  We worked on them, and they progressively got their status updated to a step in our Workflow called "Ready For QA."

The sprint ended, and I Closed the sprint.  Then we started our next sprint. 

During the 2nd sprint, the QA looked at the task and re-opened it.  But that task seems to have its Sprint field cleared (because I closed that Sprint, I think), and now the issue is sunk down deep into the Backlog.

----

What's the best-practice for others?   Some ideas I've thought about, but no idea what is 'best':

• Start Sprint 2 on-time, but don't close Sprint 1 until all issues have been verified by QA and have their resolution set to Done, etc.?
• Close Sprint 1 at the end of Sprint 1; If QA finds a problem, they should not transition that same issue back to To Do; they should create a new issue?
• Maybe the problem I'm experiencing is due to our custom Workflow step called "Ready for QA"? 

Thanks in advance for any advice anyone has to offer.   --LEO

Bill Sheboy

Hi @lsieben -- Welcome to the Atlassian community!

From my perspective, there are no such things as best practices; only better ones.  Eventually we will learn something even better.

For JIRA issues that are not completed in a sprint, their rank order in the backlog is preserved, regardless of which sprint they were in.  If they were already low in the backlog, that is where they will end up when carried over after a sprint closes.

That is a tooling constraint... what can you do to help the team's practices and workflow?

• Consider what you can finish in the sprint to achieve the goal and select that work at planning
• When work doesn't finish during the sprint, decide what to do: abandon it, put remaining work in the backlog, or select it for the next sprint.  Each time an item carries forward, it is an opportunity to learn why it happened and consider how to improve.
• When the team honestly believes a work item is "done" at the end of the sprint, call it done.  If you later discover something else to do for it, make that a new work item, and pause to consider how to see such things earlier next time.

Best regards,

Bill