Jira Agile Sprint problems with several sprint team

Hi everyone,

we have had some troubles in the past with sprints showing up on boards where they're not supposed to show up and then being closed by users, thus "destroying" the sprint.

The scenario is this:

We have many different sprint teams. In order to give our agile development some structure, we introduced a custom field called "Sprint Team". This is a select list of all the available sprint teams we have.

Each sprint team has their own scrum board, where they groom their backlog and create new sprints etc. The board filter basically shows all issues where sprint team = ABC .

However, this sometimes leads to problems like this:

Let's say we have two sprint teams: "Angry Nerds" and "Calm Bananas". Team Calm Bananas created a sprint in their board and are pulling issues from the backlog into that sprint. A day later, the sprint manager from team calm bananas goes through this future sprint ("calm sprint #1") and notices an issue that he and the sprint manager of team angry nerds agreed upon, should be done by the angry nerds team. So the calm bananas sprint manager opens the issue and changes the sprint team to "angry nerds". He refreshes his agile board and the issue is gone.

Now the manager of angry nerds opens his agile board in the plan view and suddenly sees the "calm sprint #1" with one issue in it on his board. He is confused and deletes that sprint.

A few minutes later the sprint manager of team angry nerds will come into the office of the calm bananas manager and ask him why in the world he deleted the calm bananas sprint.

I am looking for a solution to this problem. This can be as simple as displaying a warning pop-up/message, everytime the value in the custom field "Sprint Team" is being changed, i.e. "Check if the field was not empty before the new value was set. If it had a value and that value has changed, display a warning message"

However I have had no luck with my attempts using the JJUPIN plugin or the script runner from Jamie.

I am very thankful for any ideas/solutions to this problem.

4 answers

I've seen a similar behavior when moving an issue between projects. The sprint would also get copied with the issue. I believe the problem is that the sprint definition doesn't exist by itself. It's just a label on the issue. If you move or recategorize an issue the sprint label is still present on the issue and appears to have moved with the issue which is unexpected. Try removing the issue from the sprint first then reassign the team as a separate step.

Hi Dwight,

yeah that's what I told my users: first remove the issue from the sprint and then change the team, but humans make mistakes and so I'm looking for a "mechanical" solution, to minimize human errors :)

Maybe you can introduce a workflow transition for this; pre-conditions & post functions on this transition could allow you to clear/reset certain fields or prompt the user with a specific screen to capture any new field values for this transition (e.g. target 'Sprint Team' field)

See Advanced workflow configuration for more details

Perhaps a centralised sprint-management is to think abaout. we have several teams and all teams have to be ready a the same moment. So they have all the same sprint-times. Therefore only one person creates and closes the sprints. At the moment we work with one jira-project. On base of a few teamspecific requirements we will create separate jira-projects for some teams. To manage the sprints, we got a tip from Ben on another question. Perhabs that works for you as well: https://answers.atlassian.com/questions/323364/plan-sprints-for-several-teams-in-several-jira-projects

As all Teams works with the same sprints, there is no problem with moving Issues to another team.

Suggest an answer

Log in or Sign up to answer
Community showcase
Published Feb 26, 2019 in Jira Software

How to prevent the propagation of unused project schemes, workflows & screens in Jira software

Atlassian ranks project attributes as the third most important factor impacting performance in the category of data. It’s not surprising, since project attributes are precisely the rules used to ma...

572 views 0 6
Read article

Atlassian User Groups

Connect with like-minded Atlassian users at free events near you!

Find a group

Connect with like-minded Atlassian users at free events near you!

Find my local user group

Unfortunately there are no AUG chapters near you at the moment.

Start an AUG

You're one step closer to meeting fellow Atlassian users at your local meet up. Learn more about AUGs

Groups near you