What is the best way to manage sprints?

Chiranjib B March 8, 2023

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?

1 comment

Comment

Log in or Sign up to comment
Dave Mathijs
Community Leader
Community Leader
Community Leaders are connectors, ambassadors, and mentors. On the online community, they serve as thought leaders, product experts, and moderators.
March 8, 2023

Interesting discussion @Chiranjib B and I don't have an immediate answer for your hurdles/challenges. Following this topic for more insights.

The only thing I would add as a more general best practice is People over Process, Process over Tools

People Process Tools.png

Like Nic Brough -Adaptavist- likes this
Nic Brough -Adaptavist-
Rising Star
Rising Star
Rising Stars are recognized for providing high-quality answers to other users. Rising Stars receive a certificate of achievement and are on the path to becoming Community Leaders.
March 9, 2023

I'm with Dave on this one - people first, process second, your choice of tools should fall out third (and as the Atlassian fanboy, use the Atlassian suite that is built with people first.  But do not do that unless it is right - do what works best for you)

Chiranjib B March 9, 2023

Thank you for your responses, @Dave Mathijs and @Nic Brough -Adaptavist- , and let me state that I believe in the same as well, and I'm not going to prioritize a tool over people.

I was only wondering how the Product Managers had intended the product to be used. As I have mentioned in my post, I want to achieve a few things, and I am facing some challenges that I can't seem to overcome.

Nic Brough -Adaptavist-
Rising Star
Rising Star
Rising Stars are recognized for providing high-quality answers to other users. Rising Stars receive a certificate of achievement and are on the path to becoming Community Leaders.
March 10, 2023

Jira Software was built to support Scrum and Kanban.  With these, a board generally represents a team.  Your people going off and creating their own boards is not a problem, but if they're creating their own sprints, they are not working as a team.  

There's a whole load of things I could address individually in your question, but they are all down to a core problem - your people are not working as a team.

Chiranjib B March 12, 2023

Hey @Nic Brough -Adaptavist- 

Thank you for making time to respond to my concern :)

Now, I didn't mention that my team members are creating sprints. Please allow me to repaint the picture. Here's the chronology of events:

  1. I create a Board, and sprints. Let's call this Main board.
  2. One team member creates a board in their project, let's call it Secondary board. The sprints I had created start appearing on this board. This, makes sense to me.
  3. When the sprint is over, my team member closes the sprint from the Secondary board and chooses for incomplete issues to move to the next sprint.
  4. When the sprint is closed from this board, only the tickets that were part of Secondary board were moved to next sprint, and all remaining tickets stay linked to the previous sprint itself. This is what doesn't make sense to me, since I'd imagine closing the sprint from anywhere would affect all the linked tickets

Additionally, since you mention there's a whole load of things that you could address, if you would be kind enough to share your insights on how it should be done ideally, I'll be very grateful.

Cheers!

Nic Brough -Adaptavist-
Rising Star
Rising Star
Rising Stars are recognized for providing high-quality answers to other users. Rising Stars receive a certificate of achievement and are on the path to becoming Community Leaders.
March 12, 2023

Stop trying to manage sprints in different boards - they do not work the way you are guessing they do.  A sprint should be closed from the board the sprint was created in, as a board represents a sprint team.

Chiranjib B March 16, 2023

That's my wish too, and the challenge I am facing with this is - I can't restrict it for sure. If it was the original expectation in Jira that the Sprint should be managed from the board it was created on, there should be indications about it.

Right now, when I get to a sprint, there's no way to see where it was created. It only tells me the boards that it appears on.

That's what I have mentioned in my original post as well

  • There's no central place of listing all the sprints, and the boards that they were created on

I understand, appreciate and agree with what you're suggesting, but seems like there's no way to enforce the behaviour right now. If there's a way, I don't know about it yet and it would help if you could point me in the right direction.

TAGS
AUG Leaders

Atlassian Community Events