Why can't i see my issues after reopening a sprint?

[Tiemen Blankert]

I'm testing a jira automation that needs to do something on 'complete sprint'. I created a bunch of issues on this test sprint that I need for the testing. However when I reopen the sprint, I can't see my issues on the board or in my backlog under the sprint that is just reopened. The weird thing is that after refreshing 20+ times or waiting. Sometimes they suddenly reappear. But it's very frustrating to have to wait an unknown time. A couple times they didn't reappear for more than an hour.

Anybody knows why this happens and how to work around it? 

Would also appreciate better methods on how to test this kind of stuff!

Thanks in advance.

[Trudy Claspill]

Hello @Tiemen Blankert 

When you close the sprint you must choose what to do with the incomplete issues - move them into the Backlog or move them into another not-started sprint. Which are you choosing to do?

Issues will keep track in the Sprint field of all the Sprints to which they were added and remained in when the sprint was Completed. The field retains multiple Sprints, not just the current sprint.

So, when you reopen a completed sprint, the issues that were completed within that sprint will display again on the board and in the Backlog view because they remember they were in that sprint, and it is now active again.

The message about issues being moved back into the sprint regards the items that were incomplete when you completed the sprint. If they are currently in the Backlog or in another sprint that has not been started, then they will be included in the reopened sprint again. If, after the sprint was closed and before it was reopened, you moved those issues into another sprint that was active or that you started, then you would see a message about issues not being able to be moved back into the sprint you are reopening.

In my own testing of this I saw discrepancies in the display of the reopened sprint contents between the Backlog view and the Board view. The Backlog view showed the correct contents but the Board view did not. I did not wait very long to check this. It may have been a browser caching issues. I did not try to debug that specific discrepancy.

[Tiemen Blankert]

thanks for this answer and i definitely learned something from it but it is not what i mean. I choose for the incomplete issues to be moved to another sprint but thats not my problem. The problem is that the completed/resolved issues are supposed to move show on the reopened sprint. They eventually do, but it takes a variable time for them to show up. Refreshing the page or opening it in another window or logging in and out doesn't work. It somehow just takes a while and I wanted to know if there was a way to make them show up quicker again.

[Trudy Claspill]

Thank you for the clarification. As I mentioned I saw discrepancies in my own testing when reopened sprint contents displayed correctly immediately in the Backlog view showing both closed items in the sprint and any that were moved back into the sprint, but the sprint content did not display immediately in the Board view.

I had the same sort of experience as you.

I did not try to debug the reason for the delay in getting the correct issue display in the Board view.

I recommend that you report the issue to your Jira admins and ask them to escalate it to Atlassian Technical Support.

[Bill Sheboy]

Hi @Tiemen Blankert 

From what you describe, the work items may be marked as resolved and so missing on future tests with the sprint and board.  You do not describe specifics of the process, rule, how you "reset" tests, etc., so I am guessing a bit here.

When testing automation rules, particularly more complicated ones which do things to work items on Sprint started, completed, etc. events, I may use these practices:

• First, define the problem you are trying to solve; that is, "why do this".  That will save frustration when rule-writing and checking the results of tests.
• For more complicated scenarios, I always pause to draw a diagram or use blank index cards, moving them around to simulate how I expect the logic to work (i.e., Using blank cards this way is called the "naked CRC" method, where CRC is class, responsibility, and collaboration.)
• Define your test cases before you start, perhaps in GIVEN...WHEN...THEN... format or a matrix of inputs / results.  This may help you do a bit of pareto (i.e., 80 / 20) to reduce testing, and perhaps even stop when you have solved most of the problem with less effort. 
• Create a test project in a free license, test site or sandbox.  This reduces side-effects and production impacts, and reduces the chance of impacting automation usage limits.
• Unless needed for a test scenario, always create new work items for each test case.  This helps fault-isolate testing and produce consistent results to be reviewed later.  You could try these to create items for each testing round:
  • Create a CSV import file to create a set of test work items meeting your needs
  • Create a separate rule which creates new work items
  • In both the above methods, add a unique identifier to distinguish items, such as adding a date / time stamp to the Summary
• Before each test / automation rule execution, confirm what you expect and always slow down to understand results before changing the rule again
• Unfortunately, there is no version control for rules.  When making many / larger scale changes to a rule, instead disable that rule and copy it to a new one for changes.  This allows both comparison of before / after and preservation of the audit logs.  When everything works, decide what to do with the previous, in-progress rules.
• When ready for production, copy or export-import your rule to the prod environment, and retest there to confirm behaviors
• When completely done, stop, document, and explain the rule to another team member, letting them ask questions.  This knowledge sharing will pay dividends for years to come.

Kind regards,
Bill

[Tiemen Blankert]

Thanks for the practices/tips!

What I meant originally is that when you have resolved issues in a completed sprint, then reopen that sprint, the resolved issues should return back to the board. And they do, but it takes a random amount of time for them to show up and I was wondering why that happened and how to speed it up/force if possible. Sometimes I had to wait more than an hour.

To reproduce: 

make a test sprint-> put a bunch of issues in the done/resolved category-> complete the sprint -> reopen that sprint -> check back on the backlog and observe that those issues are missing.

[Bill Sheboy]

Hi @Tiemen Blankert 

I am uncertain what could cause that symptom...other than it is cloud storage and updates may need to propagate through the work items.

Have you checked if other automation rules or marketplace apps are making changes to the work items?  You can do that by find some example work items with the symptoms and then reviewing their change history.

Thanks!

[Marc -Devoteam-]

Hi @Tiemen Blankert 

To have the work items burned and mark as completed in a sprint.

The final workflow status has to be in the last column of the sprint board, otherwise if this is not the case, the work items are bot considered done in the sprint.

[Nikola Perisic]

Hello @Tiemen Blankert 

Completing and reopening isn't the same. Once the sprint gets completed, that's it. Those issues from the active sprint disappear, unless you've closed the sprint with some of the uncompleted work. In that case, all uncompleted work is moved back to the backlog to be added to the upcoming sprint.

[Tiemen Blankert]

Thanks for the reply! I'm very new to Jira so I know im probably misunderstanding a lot. 

But I wonder then why if i wait a while, the issues in 'done' dó return to the sprint? Also why do I then see this text when reopening a sprint:

"12 issues will be moved back to the sprint you're reopening.

Sub-tasks are not included in the total(s) above, and are always included in the same sprint as their parent issue."

note that those 12 issues are all in the 'done' category

[Nikola Perisic]

@Tiemen Blankert 

It makes sense for the issues to get back to Backlog when you are reopening a sprint. This is something that shouldn't really happen in Scrum. But still, you are reopening the sprint and @Trudy Claspill is correct with everything that she mentioned. 

As for the time taking of the issues to return it's more on the backend response of the server.

• Is this only happening to you, or more people?
• When you say after a while, is it like 2 minutes prior or more? I'm asking this so you can further investigate with the Network part of your development console.

[Tiemen Blankert]

It's happening for everybody in my jira environment. It sometimes takes 15 minutes and sometimes more than 2 hours. 

What do you mean with "Network part of your development console"

[Nikola Perisic]

When you go to Settings of your browser you have the option Development console. In there you have the Network tab that you can use to see how frequent these issues arise.

Is your department using a VPN?