Come for the products,
stay for the community

The Atlassian Community can help you and your team get more value out of Atlassian products and practices.

Atlassian Community about banner
Community Members
Community Events
Community Groups

Who should manage the sprint start/stop for multiple teams? An admin team or the teams themselves?


Hi there,

I work within a large Marketing department consisting of 19 teams. We have found that the best way to set-up Jira (Server) is with one project and a custom team field to filter out work for each team. We have also created separate Scrum of Scrum boards for large project based work that multiple teams contribute to.

At the moment I am trying to figure out whether to allow each of the 19 teams to start/stop/edit their own sprints or if this should be managed by one admin team.

Currently an admin team is managing this and I wondered if anyone had any experience experimenting with these options and what conclusions or considerations they found?:

  1. Pro's and con's for allowing teams to manage start/stop/edit their own sprints
  2. Pro's and con's for having one admin team manage it on behalf of the department (19 teams)

Thank you so much!

1 answer

1 vote

Hello @Amy Likoravec ,


We have a project with 7 teams.

We created 7 Boards, And For each time we created a component.

Whenever an issue is created, that must be tagged with the component name. and each scrum board is configured with a filter representing each and every component.

on sprint main board , If you want to create a sprint with all issues from 7  teams you can enable a single user / Project  admin to manage sprint. 

If you want create separate sprints for each and every team, You can create a separate role as "Team Lead" and add only users who are able to perform Sprint Start / Sprint Closse operations. And add the "Team Lead" to sprint manage permissions.

Try the one which suits your need.





Thank you for your response, however, I am specifically looking for a bit more detail about what the impacts are for both options.

I'd prefer not to make any changes until I know that nothing will break or be affected from making this change (i.e. allowing teams to manage it themselves instead of a central admin team).

So far the considerations I have found are below, however, I don't think I have considered everything or if the considerations are even correct:



  1. Ensures consistency having department on the same sprint cycle
  2. Cleaner filtering options when searching for sprints, as there is only one ‘sprint 1’, whereas if teams manage their own sprints, there would be 19 ‘sprint 1’ options, regardless of whether the same naming convention is used


  1. Reporting metrics (burndown charts, CFD) may be affected if teams don’t complete sprint planning prior to the sprint starting
  2. Reports (burndown charts, CFD) may be affected if admin team move incomplete tickets from previous sprint into the next sprint and commence the sprint, as all teams may not want this


  1. We can allocate a couple of hours window where there is no active sprint to allow teams to move issues around after a sprint has ended and prior to the next one starting. This will ensure reporting is not affected.



  1. Reporting may be more accurate
  2. There is no rush for teams to complete sprint planning by a set time


  1. Additional work for teams to manage starting and stopping their own sprints
  2. Teams may fall off the exact sprint schedule if it's not managed by an admin team
  3. The admin team may still need to start/stop a number of different boards increasing work for the team (all project based scrum of scrum boards and department boards), as version reports and burndown gadgets are based on boards
    (For context: these boards aren't for teams to specifically use but for to allow us to create version reports and burndown charts for specific projects)
  4. Reporting metrics on specific large projects may be affected if teams are starting/stopping sprints at different times, even if the variation is a couple of minutes/hours (not sure if that's right)
  5. If an issue spans across multiple teams (i.e. one story with 2x sub-tasks assigned to 2 different teams/boards), and team A has started their own sprint called 'Team A - sprint 1' containing that issue, Team B cannot start a sprint with that same issue in it for 'Team B - Sprint 1' (not sure if that's right)
  6. Will need clean naming conventions as there will be a new sprint name created for each team (unsure of how big a problem this is)




Suggest an answer

Log in or Sign up to answer

Atlassian Community Events