Closed issues being suggested to move to new sprint when completing a sprint

[Esther Strom]

A user reported this issue to me.

Their team has a sprint board with a number of tickets. All of the tickets are closed, but when they try to mark the sprint as complete, Jira is asking to move all of the tickets to either a new sprint or the backlog.

(In the screenshot, this is a board that was created using a filter that pulls in two projects. There is a sprint that contains two tickets from each project; all of the tickets are closed with Resolution = Done. The four visible tickets in the Done column are the only tickets in the sprint.)

Any idea why Jira thinks there are open tickets that need to be moved to a new sprint?

[Nic Brough -Adaptavist- · Accepted solution]

This suggests there are a number of hidden issues - the board should be showing 24 issues, not just 4.  I suspect the 4 on the board are not the 4 that are going to be carried over.

Could you do a search for "sprint = <name of sprint>" in the issue navigator and see what issues that returns, and check their status and resolutions?

[Esther Strom]

Thank you; that was it. My user did not indicate that there were other projects using that sprint that were not displaying on their board.

Wait, nope. I mean yes, there are other issues that display when I search for the sprint name. But that filter returns 7 tickets that are not Closed; why would only 4 be suggested to be moved to a new sprint/backlog?

[Nic Brough -Adaptavist-]

I think it's based on what column the issue would be in if it were on the board.

What are the status and type of the 7 unclosed issues?

[Esther Strom]

One task, four stories, two defects. The task is In Progress, the stories and defects are a mix of QA Untested, Staging Untested, and Production Untested. There are not four tickets in a single status that would account for the four it's trying to move.

Without actually clicking to complete the sprint and see which four of the seven Jira thinks should be moved, I don't know how it's deciding. 

ETA this is how the columns/statuses are mapped. So in theory, the three tickets that are in Prod Untested are considered Done, so it would be the remaining four that might be moved? OK, that sort of makes sense.

[Nic Brough -Adaptavist-]

It's the "done" column definitely.  The issues it wants to move to the next sprint are not going to be in the "done" column.  My guess on the 4/7 split is that your tasks and defects are sub-tasks, so they follow their parent into the sprint (or not) and the sprint close report is ignoring them.

[Esther Strom]

We actually don't have subtasks turned on; our tasks and defects do not have parents, unless they're part of an epic. 

This is the ticket/status breakdown:

1 story in QA Untested

1 task in In Progress

2 stories in Stage Untested

1 story in Prod Untested

2 defects in Prod Untested

So of the 7 tickets that are not actually Done (unresolved), there are 3 in Prod Untested, which maps to the Done column on the board. The remaining 4 issues are in statuses that map to various in progress statuses, and I'm assuming those are the 4 issues that Jira wants to move when the sprint is closed.

[Nic Brough -Adaptavist-]

Ah, right.  Yes, that is correct, I expect it to move the four that are not "done" because they're not in the "done" column on the right.

[Esther Strom]

Yup. So, you did answer my question, and I thank you. Can I pick your brain? We've been using Jira for 7 years, but in the past it was mostly developers just managing their own tickets. It's only recently that we've added project managers and business analysts who are managing actual sprints.

We have multiple projects going at any given time, but they are all on the same sprint/release schedule (and the code all belongs to a single codebase per language).

A given PM or BA may be managing a single project or four or five at any given time. They've taken to creating their boards based on filters that pull in all of their projects so they can swimlane them by project and see a big picture, but creating shared sprints, so that there doesn't have to be a separate Sprint 15 created and managed in a dozen different projects.

The problem with that, though, is the issue that you helped me with: in this particular case, the tickets that were "undone" and trying to be moved were not displaying on this BA's board, because they were not in one of her projects.

What is considered "best practices" for managing something like this? One thought I had, which is a major kludge, was to have a separate project called Sprints. That project wouldn't have any issues of its own. All sprints would be created in that project, and there would be a single backlog and active sprint board that would combine issues from all projects. Each PM/BA could maintain their own boards in their own projects just to monitor progress, but the actual sprints would be managed by a single PM and closed by that same PM. That way, we'd avoid the issue that occurred today.

Am I missing something? Is there a simpler way to do this? Sorry for the novel; I can open this as a new discussion, just thought I'd ask for your thoughts since you seem to have all the answers :)

[Nic Brough -Adaptavist-]

I would separate out the boards from the projects, if the project structures are working for you.  Move the PMs/BAs away from the sprints - they should have a say  in planning them, but not what goes into them.  Give them Kanban boards that show their overall picture.

Then give teams Scrum boards that select from the projects for their areas of work.  You'll need the PMs and BAs to feed into their sprint selection to give them guidance, but the teams don't need to see everything if a PM/BA is doing the job right.  You should make everyone's sprint cadence the same if you want to co-ordinate on releases.

I would have a look at the "Scaled Agile Framework" too, it has some good stuff on handling multi-team projects (albeit if you're aiming to do Agile "properly", it's still got some good ideas)

[Chris Green]

I have a similar issue @Esther Strom 

Each time we close a sprint (~monthly) there are additional issues that are rolled over to the new sprint

Within each sprint, we do a number of releases and 'releasing' the tickets in JIRA sets the status of the tickets in that release (aka fix version) to 'Closed'

Only 1 sprint is active at any time, and the 'Active sprints' Board, currently containing 90 tickets of type Bug, Task, Epic, Spike, Improvement, New Feature (no sub-tasks), in status'
Reopened, In Progress, Under Review, Ready for QA (No 'Done' or 'Closed' tickets)

The 'Backlog' view contains 1 active sprint and 2 inactive (future) sprints and a Backlog

On the 'Column Management' page (RapidBoard.jspa?rapidView=12&config=columns) there are 2779 issues showing as 'Done'

When trying to close the sprint it shows "0 issues were done" (consistent with the above) but then shows "511 issues were incomplete"

When I search issues by Sprint 520 issues appear, 429 of which imported in to the sprint from the last sprint as "Closed" (with varying resolutions, Duplicate, Won't Do, Done, Not Applicable, etc) from as far back as June 2016 that have been rolled through 17 different sprints

This affects the burndown chart, as the story points are not shown as released at the end of any sprints

I tried doing a bulk action to Close all tickets, but they still rolled over to the next sprint