I've been managing the Jira deployment for my organization, and have streamlined a few aspects of the setup to achieve consistency across Projects. The only aspect that doesn't sit well with me so far, is the Sprint Management.
Let me describe our setup a little bit:
- There is a Release Management project that has the "master" Board, which encompasses issues from various Projects. It has a dedicated Workflow Scheme and Permission Scheme
- We declare sprints originally in this project's Board, with non-overlapping date ranges. Also, we don't allow parallel sprint in projects.
Here's what we want to achieve:
- Every sprint release is managed by a different individual, and they are expected to close the current sprint and start the next sprint (the permission for this as I understand is driven by the permission scheme of all the individual projects contributing to the Board)
- For every sprint, we want to capture the committed scope (when a sprint is started) and the completed scope (when a sprint is closed)
Hurdles we are facing:
- People are creating Boards in their individual projects for convenience. This causes the sprint(s) to appear in those Boards too. As humans are prone to error, sometimes someone starts/closes a sprint from a project specific Board, which only affects a subset of tickets linked to that sprint. Challenges with this:
- I want to restrict people from managing sprint from project Boards. I can not achieve this in a project specific permission scheme, as this will affect the ability of sprint management in the "master" Board too
- Whenever a sprint is closed from a project Board, all the tickets that are not part of the project Board, are not moved to the next sprint, and we have to spend extra effort to identify those and bulk change to be linked to the next sprint
- If we bulk change and edit the sprint field, it overwrites old data.
Example: Let's say some issues were in Sprint 1, and didn't get carried over to Sprint 2 owing to the behaviour I specified above. Now if we Bulk Edit these, the sprint field only shows Sprint 2, and we lose the information that it was spilled from Sprint 1.
- Whenever unresolved issues are shifted to the next sprint, the history of tickets doesn't capture this event.
- There's no central place of listing all the sprints, and the boards that they were created on
- Exploring Automation for Jira, the sprint triggers are defined for a specific Board. Now, if people are allowed to manage sprints from any board whatsoever, then I can't define a trigger for "master Board" and rest assured that I will achieve the output I desire.
All that put together, I feel I still don't understand the right way to manage sprints as Atlassian had intended. Can anyone point me in the right direction, if I am straying?
