Where to find logs about sprint interaction?

unknown

Hi

[Square brackets are context info]
[There was an extraordinary event, and we would like to verify a hypothesis or figure out if something else happened. I would normally request support ticket, but corporate policy digitally restricts the use of any browser except Edge, and Edge has captcha load script error on support page, preventing to submit any ticket from my side.]

[TLDR: read only bold]
Observation: While having daily scrum, 10 of us witnessed Issues disappearing from our active sprint in real time, and finally the sprint has also become unavailable. Concurrently, another project's PO explained to me [Scrum Master] that she had an empty sprint from our project appearing in her project, so she decided to delete it as it made no sense to have our sprint in her project. Yes, the two events sound relating. What we figured out, the "lost" Issues got has landed in an old, deleted "Grooming" Sprint of our project, but using Issue browser we could set them to be in a brand new created interim sprint. 

Question: Where/How can we check past actions on Sprints? (8th October in this case)
[We want know what happened on system level, and see if the specific user had relevant deletion action on our sprint, and if that has triggered the observed events.]
On Issues a generic log is available for all(?) users. [Issue logs show that user to set different sprint to each, but no info on the sprint]
On system events an admin access level log is available, but the past 3 months logs do not contain any sprint interactions (creation, start/stop, deletion, etc.) however we have ~100 projects running.

What would be the proper place, I could find such information at? 

Thank you for reading and sharing ideas

Zoltan

Trudy P Claspill

There are no logs for activities against a sprint that are readily available to users/admins of Jira.

Here is some information about sprints which you may not know. Forgive me if you already know this information.

A Sprint will appear in a board if either of these conditions is met:

1. The sprint was created in that board

2. The sprint has an issue assigned to it that is within the scope of the board's filter, even if the sprint was not created in that board.

 

Another fact about sprints is that Jira does not require sprint names to be unique across the Jira instance. Multiple boards may independently each create a sprint with the same name (i.e. "Sprint 1"). 

Another fact is that Jira does not restrict which issue can be added to a sprint. If Sprint 1 is created in a board for project XYZ, there is nothing that prevents issues in project ABC from being added to the sprint. A user just has to edit the Sprint field directly in the issues in project ABC and enter "Sprint 1" in that field.

Because of the above two facts, it can be very confusing if there are multiple sprints with identical names. A user may edit an issue directly and add it to Sprint 1 thinking they are adding it to Sprint 1 for their board, when they are actually adding it to Sprint 1 that was created in another team's board.

 

All of this is to highlight that the "empty" sprint that the PM saw may actually have been created in that team's board, not yours. It would show up in that team's board only if it was created there or if it had an issue in it that was within that board's scope. Since it appeared empty on that board, that suggests it was created in that board. And the fact that your team's issues were in it and the sprint showed up on your board could indicate that somebody erroneously assigned one of your team's issues to that sprint.

Once the sprint is showing up on another team's board, that other team might rename the sprint, which can add to the confusion. Perhaps it had a generic name like Sprint 1, but once it started appearing on your board a member of your team change the sprint name to be specific to your team. It would then look like the sprint was owned by your team, while in fact it was created in another team's board.

Lastly, before a seemingly empty sprint is deleted, one should always use the Issue Search screen to search for issues in that sprint. As you type in "sprint=<name of sprint>" you will see potential matching sprint names. This will highlight if there are multiple sprints with identical names. And the results will show if there are issues from unexpected projects in the sprint, where those issues were not being seen on a board displaying the sprint.

So, while you cannot conclusively block these sorts of things from happening, you can mitigate them by educating your users on the above facts, AND advising your scrum/board master to make sure they name their sprints during creation in a way that clearly identifies the owning team/board.