nav[aria-label="Primary Navigation"] { padding: 0; & ul { list-style: none; width: 100%; display: flex; flex-direction: row; justify-content: start; align-items: start; gap: 30px; padding: 0; & li { margin: 0; } & ul li { list-style: none; } } }

Unresolved issues disappear from Scrum board when sprint is completed

Simon Duerr

Hi!

We have a problem with unresolved issues disappearing from the scrum board after a sprint is closed.

Details:

In our project, developers are moving issues from status "open" (via some other stati) to "testing" (status category "In Progress"), after which our testers take over and set its status to "done" (status category "Done").

As the project is large, the devs don't want 50 or more issues per sprint in the "done" column, so they removed it => the rightmost colum is now the one with status "testing".

The weird thing is, if they complete the sprint, all issues in the "testing" status/column are marked as "Completed" in the sprint report and disappear from the backlog.

==> How does Jira mark those issues as "completed"? Which field am i missing?

It's not resolution nor status nor the status category. The sprint field can also be empty as backlog issues do have an empty sprint field...

And the other question is: Why is jira determining issue completion upon "active sprint board column" rather than than "status category" or "resolution"?

Accepted answers

Nic Brough -Adaptavist-

Welcome to the Community!

For baords, there's a very simple concept that your developers are not handling correctly.

The last column on the board is "done".

That's it, really. There's conversations to be had on whether that's the best way to do it, multiple columns, and how you should try to make status and resolution line up with that last column, but there's not a lot more than "last column = done" to this one.

To fix this problem, put the "done" column back, and tell the developers they're breaking everything if they do not represent "done" correctly!

Simon Duerr

Conclusion:

The Scrum board seems to filter any issues

from backlog/sprints/active sprint that are in a status not mapped to a column

from backlog/open sprints that are in a status mapped to the rightmost column

This is similar to the kanban board sub-filter, but unfortunately cannot be configured

All comments

Nic Brough -Adaptavist-

Welcome to the Community!

For baords, there's a very simple concept that your developers are not handling correctly.

The last column on the board is "done".

To fix this problem, put the "done" column back, and tell the developers they're breaking everything if they do not represent "done" correctly!

Simon Duerr

Hi Nic, thanks for the welcome and super fast response!

We have this setup because the tasks in the "testing" status/column are being processed by the testers in an external tool, therefore anything beyond "testing" is out of scope for the devs, and the testers use their own tool.

I'm aware of the fact that the tool is not used as intended, but i'd like to understand what's going on behind the scenes.

The content of the sprint field (in the issue screen) ist the same when moving a task to the rightmost column/status and closing the sprint, as it is when a task is in "open/ToDo" status when the sprint is closed, ant then moved to the backlog. Both task's "Sprint"-field contains "None +1" (where +1 stands for the sprint that has just been closed), but the task that was in the rightmost column is not shown on the board anymore, while the other one is present.

I found out the following by trying around...

If you transition an issue to a status, that's not assigned to a column, it disappears from backlog and all sprints, including the active sprint
If you transition an issue to the status in the rightmost column, it disappears from the backlog and in other sprints BUT NOT from the active sprint
If you change the status-to-columng assignment in the board settings, you can make issues appear and disappear, depending on which state is in the rightmost column.

Simon Duerr

Conclusion:

The Scrum board seems to filter any issues

from backlog/sprints/active sprint that are in a status not mapped to a column

from backlog/open sprints that are in a status mapped to the rightmost column

This is similar to the kanban board sub-filter, but unfortunately cannot be configured

Nic Brough -Adaptavist-

Yes, that's all right. The board is supposed to represent the sprint, and the last column "done in this sprint".

So, to explain the behaviour in your three points:

If you transition an issue to a status, that's not assigned to a column, it disappears from backlog and all sprints, including the active sprint
- Yes, because you don't have the status on the board, the issue is not on the board, so it's obviously not of interest to the team, they're not going to work on it. If they're not going to work on it, there's no point having it in their backlog either. The backlog and board are actually the same view, looking at the same issues, they're running the same code to decide what to display. The board just has one more clause applied - "in the current sprint"
If you transition an issue to the status in the rightmost column, it disappears from the backlog and in other sprints BUT NOT from the active sprint
- It's because the issue is done if it's in the last column. It stays in the column on the board, because the board is showing you everything in the sprint
If you change the status-to-columng assignment in the board settings, you can make issues appear and disappear, depending on which state is in the rightmost column.
- Yes, you're effectively changing whether an issue is done or not

So, yes, it's not obvious how these things work, but they are this way for a reason. I can't "fix" the problem you've got, because it's down to not using the board as they're intended to be used, not the configuration of the tool.

But hopefully an understanding of why it works this way helps explain it to your teams.

Simon Duerr

Thanks again, I see your points.

It's somehow confusing that an issue is considiered "Done" based on column settings rather than Resolution field or StatusCategory, especially if you consider that a project can have multiple boards - issues are Done on one board, not done on another?

==> This can actually be a valid use case. If you have a long workflow with let's say 9 steps, steps 1-5 can be processed by team A on board A, steps 5-10 by Team B on board B. Altough working in the same project, both teams can have their separate backlog and sprints without any interference. => Now i'm convinced that it's a feature, not a bug ;-)

Welcome!

It looks like you're new here. Sign in or register to get started.

Quick Links

Find more posts tagged with

cloud

jira-software

jira-software-cloud