Create
cancel
Showing results for 
Search instead for 
Did you mean: 
Sign up Log in
Deleted user
0 / 0 points
Next:
badges earned

Your Points Tracker
Challenges
Leaderboard
  • Global
  • Feed

Badge for your thoughts?

You're enrolled in our new beta rewards program. Join our group to get the inside scoop and share your feedback.

Join group
Recognition
Give the gift of kudos
You have 0 kudos available to give
Who do you want to recognize?
Why do you want to recognize them?
Kudos
Great job appreciating your peers!
Check back soon to give more kudos.

Past Kudos Given
No kudos given
You haven't given any kudos yet. Share the love above and you'll see it here.

It's not the same without you

Join the community to find out what other Atlassian users are discussing, debating and creating.

Atlassian Community Hero Image Collage

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

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.

 

Thanks,

Anvesh

Hi @KAGITHALA BABU ANVESH

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:

ADMIN MANAGES SPRINT START/STOP/EDIT

Pros

  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

Cons

  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

Solution

  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.

TEAMS MANAGE OWN SPRINT START/STOP/EDIT

Pros

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

Cons

  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)

 

Thanks

Amy 

Suggest an answer

Log in or Sign up to answer
TAGS
Community showcase
Published in Agile

Join us LIVE: Atlassian & Experts Talk Research & Insights @ Scale

Hello all! What have you learned from your customers lately? Our live-streamed series continues by exploring CX, UX, and the power of research & insights at scale with Leisa Reichelt, Head of R...

366 views 3 8
Read article

Community Events

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

Find an event

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

Unfortunately there are no Community Events near you at the moment.

Host an event

You're one step closer to meeting fellow Atlassian users at your local event. Learn more about Community Events

Events near you