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.
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.
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...
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!
Unfortunately there are no AUG chapters near you at the moment.Start an AUG