Hi everyone, I've been reading a bunch of threads on this topic but am hoping I can get some clarity on if the issue I'm running into is expected or if I can find a resolution. Issue: An issue that is in the furthest right column on a Sprint Board is automatically moving to the next sprint. My expectation is that it wouldn't move. Configuration: (I think this might be the reason but hoping anyone here can identify the problem) * Let's say I have the following 2 separate Sprint Boards* Board A:* Sprint Board columns are the following:* (furthest left) To Do * In Progress * QA * (furthest right) Done * Board B:* Sprint Board columns are the following:* (furthest left) To Do * In Progress * (furthest right) QA & Done * I have the following issue AB-123 that appears on both boards and has a status = QA* On Board A it would appear in the QA column * On Board B it would appear in the furthest right QA & Done column * Other info:* Status Category of QA is In Progress Situation: * When the sprint issue AB-123 is assigned to ends, Jira is automatically moving this issue into the next sprint. Therefore, in Board A issue AB-123 is showing in the QA column and Board B is showing in the QA & Done column Question: Is Jira moving the issue because on Board A QA is not the furthest right column and therefore Jira doesn't consider the issue to be complete? Or could it be because the Status Category of QA isn't Done? Possible Solution? * To prevent the above from happening would setting Status Category of QA = Done resolve this? * or would we need to audit all the sprint boards to ensure QA is also mapped to the furthest right column? Thank you for the help, Joe

Understood. Thanks @Bill Sheboy

@Joseph Wilkinson -- Short answer: not with built-in features. That would require checking each board / filter in the site to check if a work item is returned by it. Theoretically...one could write an app which gathers all boards using a REST API endpoint, and then use another endpoint to gather the work items on the board (or their filter) to check.

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; } } }

Issue on Sprint Board in furthest right column moves to next sprint

Joseph Wilkinson

Hi everyone, I've been reading a bunch of threads on this topic but am hoping I can get some clarity on if the issue I'm running into is expected or if I can find a resolution.

Issue: An issue that is in the furthest right column on a Sprint Board is automatically moving to the next sprint. My expectation is that it wouldn't move.

Configuration: (I think this might be the reason but hoping anyone here can identify the problem)

Let's say I have the following 2 separate Sprint Boards
- Board A:
  - Sprint Board columns are the following:
    - (furthest left) To Do
    - In Progress
    - QA
    - (furthest right) Done
- Board B:
  - Sprint Board columns are the following:
    - (furthest left) To Do
    - In Progress
    - (furthest right) QA & Done
I have the following issue AB-123 that appears on both boards and has a status = QA
- On Board A it would appear in the QA column
- On Board B it would appear in the furthest right QA & Done column
Other info:
- Status Category of QA is In Progress

Situation:

When the sprint issue AB-123 is assigned to ends, Jira is automatically moving this issue into the next sprint. Therefore, in Board A issue AB-123 is showing in the QA column and Board B is showing in the QA & Done column

Question: Is Jira moving the issue because on Board A QA is not the furthest right column and therefore Jira doesn't consider the issue to be complete? Or could it be because the Status Category of QA isn't Done?

Possible Solution?

To prevent the above from happening would setting Status Category of QA = Done resolve this?
or would we need to audit all the sprint boards to ensure QA is also mapped to the furthest right column?

Thank you for the help,

Joe

Accepted answers

All comments

Marc -Devoteam-

Hi @Joseph Wilkinson

This is because the status category of the status QA is not a "Done" status.

To have issues being considered "burned" in a Sprint, the last column of the sprint board needs to contain statuses based on the "Done" category.

If the last column of a board includes statuses from the categories "To Do" or "In Progress" the issue is not considered "burned" and they will be moved to the next sprint or to the backlog, based on the decision made on closing the sprint.

If a status with is in status category "Done" is not in the last column of the board, the issues in this status will also not be considered "burned".

Joseph Wilkinson

Thanks @Marc -Devoteam- I will do some testing by changing the Status Category of QA from In Progress to Done to see if this fixes what developers are seeing. Appreciate the quick reply

Joseph Wilkinson

@Marc -Devoteam- out of curiosity do you feel the 2nd solution posted above is also a possibly solution without having to change the Status Category?

or would we need to audit all the sprint boards to ensure QA is also mapped to the furthest right column?

I did some limited testing using 2 boards and believe this could also work but poses lots of challenges

Bill Sheboy

Hi @Joseph Wilkinson

First a question: would you please describe your team(s) process such that the single work item is on two different Scrum boards? I have observed this for Kanban boards with interconnected team flows yet not for Scrum.

The status category has no impact on completion: Jira Scrum boards determine "completed" for a sprint when the work item is in a status mapped to the far-right board column. For the scenario you describe, the work item is in two different sprints, and it is incomplete for one of them.

Kind regards,
Bill

Marc -Devoteam-

Hi @Joseph Wilkinson

I see I was incorrect, any item in the last column of the board is considered done in a sprint not regarding the status category.

But as you have 2 board, based on the same sprint and QA is not in the last column in one of the boards the issue is not considered done.

Joseph Wilkinson

Thanks @Bill Sheboy the way teams work here is in the past we have a single Sprint Board (let's call it Master) where all the sprints are an entire year are created. The sprint has set up to start, stop, and rollover any open issues to the next sprint. From there teams create their individual sprint boards that filter down issues to what is most relevant to them. This is why you can have the same issue across multiple sprint boards. I'm trying to find out why on one board Jira will move an issue to the next sprint when the status the issue is in is configured with the furthest right column for that board.

It sounds like if an issue is on multiple sprint boards, then each sprint board status to column configuration should be the same?

Joseph Wilkinson

I accidentally posted my comment in the wrong position so repasting here:

It sounds like if an issue is on multiple sprint boards, then each sprint board status to column configuration should be the same?

Bill Sheboy

Thanks for that information, @Joseph Wilkinson For overall, "monitoring views" of multiple Scrum team boards, I have also seen a single Kanban board which shows the rollup.

Back to your question: yes, I believe for multiple Jira Scrum boards as you describe, the column mappings of ["not started", "in progress", "completed"] statuses must all match or be mapped to act as a "rollup" of them.

For example, let's assume 2 Scrum teams with board columns of a single status:

Team Apple: todo, build, test, done
Team Squirrel: todo, in progress, verify, validate, releasing, done

The "rollup" one could be like this, with status values mapped:

To Do

Building

Testing

Releasing

Done

todo

Build

In Progress

Test

Verify

Validate

Releasing

Done

Joseph Wilkinson

Thanks for the guidance and help @Marc -Devoteam- and @Bill Sheboy I'll take this back to the team. Out of curiosity is there a way to see which Sprint Board(s) a particular issue is on?

Welcome!

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

Quick Links

Find more posts tagged with

jira

cloud

jira-cloud