Why are some stories disappearing from the board on status change?

[Sander H]

We've been experiencing stories that disappear from the Scrum boards we use for a number of projects. It always happens to stories that are carried over from the previous sprint, so they are assigned two sprints (one completed, one active).

When changing the story's status (e.g. from 'in progress' to 'review') it suddenly disappears from the board. It is then visible at the bottom of the backlog. 

Changing the status (or one of the other fields) usually brings the story back to the board.

I've tried reindexing the concerning project (as per Atlassian recommendation, https://confluence.atlassian.com/jirakb/issues-are-not-appearing-in-boards-779159013.html), but to no avail. I've verified the issue is showing up in the board query.

 The workflow hasn't been changed in about a year, yet this issue started happening some weeks ago. We're using Jira V8.2.1.

Does anyone know why this happens, or what I can do to resolve the issue?

[Sander H · Accepted solution]

The mapping is fine, I guess. This behaviour only affects some of the stories on the boards (1 out of maybe 20?) and only  stories that have two sprints assigned (see description).

All other stories transition fine between the four statuses. 

[Andy - PTC Redundant]

Just out of interest and to test all options:

Are you removing the Story from the sprint to the backlog before you move it to the new sprint?

When you say "assigned to two sprints" - why is it left assigned to the original sprint? I would prefer to see it completely detached from the Sprint. 

[Sander H]

We use the 'close sprint' dialog to move the unfinished issues to a new sprint. This apparently causes the double sprint assignment. I take it this is a feature, in order to track issues that are planned for a sprint but not finished in it?

It would be inconvenient, but it might be worth a try to move them to the backlog first. 

[Andy - PTC Redundant]

Hmmm... strange that you are doing this correctly and yet still the issue remains!

You can try to remove them to manually back to the back-log first.
This will still be view-able as historical data in such items as Sprint Reports.

That said - doesn't resolve this bizarre issue!
If Nic and Jack can't work it out... then no one can (IMHO)... could be a bug. Worth a support ticket if the gents can't help in the end.

[Jack Brickey]

@Sander H , the fact that the previous sprint remains is indeed a designed behavior. While you could elect to remove the previous sprints you will loose the history, e.g. when you go to reports and look at old sprints. I'm not 100% sure but would expect it would mess up your velocity. Basically, removing old sprints from Sprint field will invalidate your scrum history. Again, i have not done an exhaustive study on this.

In any event this isn't associated w/ your current issue I believe. you do mention that the issue only occurs on issues w/ multiple sprints (smoking gun?). But then again you seem to also be saying that it doesn't happen on all issues w/ multiple sprints so that seems to negate the smoking gun theory.

[Sander H]

I just verified that what you state is correct, it doesn't happen for all issues that are assigned to multiple sprints.

[Jack Brickey]

i'm truly baffled at the moment. something obvious we are missing or a nasty bug. Random thoughts:

1. inspect several of the "disappearing issues" closely to see if there is something unique w/ them vs. the "always visible" issues. Maybe there is something that will expose a clue here.
2. build a completely new board to replace the other board and monitor for this behavior. It doesn't sound like you can reproduce at will.
3. It might be interesting to take one of the "disappearing issues" that have since been closed/released and see if you can recreate. You could either reopen and drag it thru the columns or, if that is not desirable, you might try cloning it. This would be an interesting test for sure since if it is reproducible then we might be able to zero in on why. If it does not reproduce then it would seem to place more validity to a possible bug.

[Sander H]

Hi Jack,

Thanks for the suggestions, I really appreciate you guys taking the time to try and figure this out with me.

1. Will continue to do that when new cases pop up, preliminary results showed only the double sprint assignment as 'unique' quality.

2. I've created another board for one of the projects (with the same status mapping, or did you intend something else?) although, since the stories that are affected actually show up at the bottom of the backlog, I don't think it's the board that is the issue.

3. Changing the description got the story back on the board, seen the same behaviour changing other fields. Moving that story back and forth between the four statuses about 40 times did not reproduce the issue.

Is there some way I can view the 'raw' story information/fields to check if that yields any clue? 

[bdaun]

Hello, we have seen this issue in one of our Kanban boards as well. Our current guess is that the stories have reached a time limit, and they're no longer displaying after a certain time frame, but we haven't been able to find anything to confirm our suspicions. 

Has there been any resolution on this?

Please let me know if you need any more details, thanks! 

[Sander H]

Hi bdaun,

The only 'solution' so far is to move all stories to the backlog when completing the sprint, and manually adding them to the new one. Since I started doing that I haven't had the issue anymore. Kinda lame, but it beats having stories disappear from the board :)

Best regards,

Sander

[Sander H]

Sadly, even that is not true.

We're using the suggested work around of transferring unfinished stories to the backlog when closing a sprint, then manually assigning them to the next sprint, but we just got the first case of a story disappearing from the board since using the work around. Which means that is *not* a solution either.

Someone from Atlassian should seriously look into this... 

[Nic Brough -Adaptavist-]

I'd agree it's time for Atlassian support.  Have you raised it with them yet?

[Sander H]

No, I didn't yet. I'm not sure what steps to follow here. Could you let me know what channel to use for this?

[Jack Brickey]

Use this link - https://support.atlassian.com/contact/#/ 

@Sander H , we will be keenly interested in the final outcome. Please post here.

[Sander H]

It seems the issue has been fixed!

The bug was caused by application link threads (which run the DVCS plugin) bypassing Jira filters and not triggering ThreadLocal-RequestCache deletion.

This has been resolved in versions 8.5.5+ as well as 8.6.0 and above. The best way forward will be to upgrade your instance to any of the versions containing the fix. The related bug ticket has also been marked as resolved as a result of these findings .

JRASERVER-71091: Development Activity breaks Sprint indexes (fixed in Jira Server and Data Center 8.6.0, 8.5.5)

Thanks to Sherif for his great support!

[Sander H]

An attentive and active Atlassian support employee managed to diagnose this and linked this issue to https://jira.atlassian.com/browse/JRASERVER-71091

It seems to be triggered by sprint activity (e.g. making a pull request), followed by transitioning of the story. When these happen in a short time frame, the link between sprint and story can be 'lost'. Reindexing the story using the REST API resolves the issue, but then again so does any other modification to the story.

If you're experiencing the same issue, please vote for it!

[Sander H]

The support ticket with Atlassian is taking a rather long time as (while they have confirmed the issue in a screen sharing session) they are not able to reproduce it.

When creating a HAR file (one of the step requested by support) I had to disable the caching in the browser (in chrome: developer tools -> network tab -> Disable cache checkbox). Upon reloading the page, the two stories that were affected at that time magically reappeared on the scrum board.

I have not been able to verify if disabling the cache is the step that resolved the issue as I have not had any live example of an affected story since.

So I would like to ask anyone experiencing the issue:

Can you try disabling caching the your browser, reload and report if this resolved the issue?

[Sander H]

Just been able to try that; didn't resolve the situation.

[Jack Brickey]

So is the issue still being investigated by support?

[Sander H]

Yes, previous support attempts failed to reproduce the issue so they requested a HAR file.

I was now able to create that HAR file with a story that exhibits this problem, so I've added that to the support ticket.

With that, I've just reopened the issue.

[Nic Brough -Adaptavist-]

Could you show us the board filter, and an issue that should be appearing on the board but is not?

[Nic Brough -Adaptavist-]

Could you check the mapping of status on the board?  As you say they disappear when the status changes, it sounds like the new status is not mapped into a column on the board, so they won't be displayed.

[Sander H]

Sure, see attached screenshots. It happens at least once a week, so I would really love to get this resolved. Thanks for your replies so far Nic!

[Jack Brickey]

This is certainly a head scratcher. To be clear you are dragging and dropping when this mysterious disappearance occurs vs. setting the new status in detailed view, right?  Not that it should matter here but curious. Is this a single project board? Could you share your board filter too?

[Sander H]

Correct, the transitions are done by dragging and dropping.

The issue occurred on two separate boards (using the same issue types and workflow).

I think this is the information you wanted to see? If there's anything else that might help, please let me know.

[Jack Brickey]

Everything looks clean. I’m at a loss here. Only random wild considerations 

interop issue with addon

swimlane config oddity

bug

@Nic Brough -Adaptavist- 

??

[Nic Brough -Adaptavist-]

Are there any quickfilters set up on the board?  If so, are any of them active and could it be them?

It does look a bit odd when someone has a quickfilter for "status != 'in review'" (or something that works on other fields amended by a transition - like a group-picker or assignee etc) as dropping an issue into the "in review" column will make it vanish when the filter is enabled.

[Sander H]

No quickfilters are active (we just have the 2 default ones, 'my issues' and 'recently updated').

[Nic Brough -Adaptavist-]

I was about to say almost what Jack said!

I think my grasping-at-straws "look at quickfilters" is firmly ruled out as the problem.