nav[aria-label="Primary Navigation"] { padding: 0; & ul { list-style: none; width: 100%; display: flex; flex-direction: row; justify-content: start; align-items: start; gap: 30px; padding: 0; & li { margin: 0; } & ul li { list-style: none; } } }

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

Amy Likoravec

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?:

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

Thank you so much!

Comments

KAGITHALA BABU ANVESH_z1zl10

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

Amy Likoravec

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

Ensures consistency having department on the same sprint cycle
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

Reporting metrics (burndown charts, CFD) may be affected if teams don’t complete sprint planning prior to the sprint starting
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

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

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

Cons

Additional work for teams to manage starting and stopping their own sprints
Teams may fall off the exact sprint schedule if it's not managed by an admin team
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)
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)
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)
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

Welcome!

It looks like you're new here. Sign in or register to get started.

Quick Links

Find more posts tagged with

agile

scrum

sprint