Disable adding/removing tickets to Active Sprint

Question

Once the Sprint is started, we notice that there are still issues being added/removed to/from the active sprint, can we disable the editing of Sprint field for certain users so that they can't add or remove issues from a Sprint?

I want only the Project Managers or Scrum Masters to have complete control of the issues being added to or removed from the Sprint, but that isn't the case and it is being misused by developers to add and remove tickets at their own will.

Bill Sheboy · Answer

Something that may help with that conversation...

Discuss what types of work the team does (e.g., planned, unplanned, urgent prod support, etc.), what classes of service the team uses (e.g., how to respond), and how those map to the work item types.

For example, if the team and the PM have a shared understanding of "urgent prod support" and how to respond when something of that type arrives, there will be no surprises if such a thing is added to scope.  Similarly, if other additions / removals can wait for a team chat with the PM, everyone on the team will feel empowered and accountable to speak up on work management with one another.

As a bonus benefit: understanding the work item types and classes of service will help the team track how much work fits those criteria over time, sprint by sprint, allowing better planning by anticipating the impacts.

Varun Modi_sqy3my · Answer

Hi @Bill Sheboy,

I totally agree to what you said, there are definitely a lot of consequences of fixing this at the tooling level rather than understanding the deep reason behind it.

I am not against adding or removing issues in the Sprint.

In order to fix this, whenever a issue needs to be added/removed to the Sprint, I would like it to be discussed and brought up with respective PM or Scrum master rather than everyone adding the tickets themselves as they like.

It would help the PM or Scrum master better understand not just why a ticket needs to be added or removed but also what is going wrong with the current planning which will make the team's ability to get better at planning and estimation.

Bill Sheboy · Answer

Hi @Varun Modi

I respectfully suggest when only tooling is used to prevent changes to a sprint's scope in Jira, there will be unintended consequences, such as:

* some work will happen that is not tracked in the sprint
* some completed work will be unknown / unsupportable by others on the team
* planned work will take longer than is expected, or be of lower delivery quality
* the team's ability to forecast and plan work will become less reliable
* stakeholders may develop concerns resulting from the above things
* etc.

Instead consider working with the team to understand why items are added / removed from the team's sprint plan.  Knowing those things will help to uncover the root causes, and to develop actions to mitigate or resolve them.  And tracking of scope changes over time will help identify progress on addressing the causes.

Kind regards,
Bill