Who decides if something should NOT be injected into a Sprint?

Question

On some teams, I've seen it be a combination of operations and Product Management stating that either new/missed requirements came in, or bugs are severe enough to warrant injection. The Scrum Team then does a bit of investigation to understand scope, they refine it, inject it, and get it done.

I ask because at present, there really doesn't seem to be a boundary on what is determined to be injectable, and the team is just accustomed to working on whatever/whenever Product decides is top priority.

I don't believe Scrum Masters themselves have the ability to veto an injection, though they possess the governor by slowing things down to talk through why this needs to be injected. Developers don't have the ability to veto an injection. Product Management is the requestor of the injection. Does it lie outside of the Scrum Team, or maybe with Dev/Release Management?

Answer 1

This is going to be a pretty by the rules answer. Before I give you that, remember that you're working with people and that if the developers and product owner have a good conversation and decide it's worth it, then who cares?

As a Professional Scrum trainer with Scrum.org, my by the book answer would be this:

The sprint backlog consists of the work selected by the developers to meet the sprint goal and their plan to deliver that work. It's their plan, their commitment, thier goal.

There are 2 people who can initiate the renegotiation of the scope.

1. The developers. For any reason that endangers the sprint goal, causes the product to be undone or when they find out they have too much or too little work, the developers can reach out to the product owner to renegotiate the scope of the sprint. The scope can usually only be changed if it does not cause the sprint goal to be endangered.
2. The product owner. The product owner can request the developers to consider changing selected work for the sprint. Ideally when the product owner has found better or alternate ways to achieve the sprint goal or when something urgent has come up which could be added to the srpint backlog without endangering the sprint goal. Ideally this would cause some other work to be removed from the sprint backlog.

A team can't infinitely add more work to the sprint. Though many teams leave some room in their plan to deal with these kinds of "unexpected issues", if they pop up regularly.

The Product Owner has one final instrument to force a scope change, they could cancel the sprint. This would cause an immediate replanning and renegotiation of the sprint goal. A Product Owner should only do this when not delivering the current sprint goal weighs up to delivering the new goal. e.g. when the sprint goal has become obsolete.

The developers could also force the hand of the product owner if the defect that was found is so severe that they would consider the product no longer in a done state. E.g. a security vulnerability is found, and it must be fixed. In that case they could opt to fix the issue as part of whatever work they're working on now. They couldn't deliver the increment otherwise, since a Scrum Team only delivers increment that adhere to the Definition of Done.

The Scrum Master's role in this is to ensure:

• That the Product Owner doesn't change scope on a whim.
• That the developers don't deliver increments that don't adhere to the Definition of Done.
• No outsider of the Scrum Team overrules the shared decision of the Scrum Team.

The Scrum Master could use the Retrospective to help the team explore why these issues happen regularly. And what could the Scrum Team do to either fix that situation or for them to be in a better form to handle these kinds of issues (e.g., fix them with far less effort and faster so that they're less of a problem). If this happens frequently and the team can't immediately resolve the cause or speed up the delivery, they could opt to leave room in their sprint plan to handle these kinds of issues by simply planning less work.

Answer 2

Since Scrum Teams are self-organizing and self-managing, the specifics are going to vary by team. Different teams will find a way of working that works for them. However, there are some general ideas that can be derived from the Scrum framework as a starting point.

The Product Owner is "accountable for maximizing the value of the product resulting from the work of the Scrum Team". This can be interpreted to mean that the Product Owner can decide if work is important enough to interrupt the Scrum Team with immediately or if the work can be put onto the Product Backlog for refinement and selection in an upcoming Sprint.

If the work is more important than the most important thing that the team is currently working on, the Product Owner may choose to bring it to the Scrum Team. This doesn't necessarily mean that the team will solve the problem immediately. It may mean that the team can look at it briefly and let the Product Owner know what the impact would be. The team may find a temporary workaround to whatever problem is that doesn't require immediate effort. The team may also find that the level of work is small and won't impact the team's ability to meet the Sprint Goal. The team may also find that the work is very large and complex and would put achieving the Sprint Goal in jeopardy. The Product Owner and Developers can work together to decide the best course of action to maximize value for the stakeholders.

According to the Scrum Guide, the Sprint Backlog is "a plan by and for the Developers". This means that the Developers are responsible for choosing what they work on during a Sprint and no one can tell them what or how to take on work. However, this requires that the Developers understand the implications of their decisions for stakeholders. It would be unprofessional for Developers to blindly reject critical work just because it wasn't planned for in their Sprint.

Sprint Planning should account for these unknown unknowns that could arise. During a Sprint, things could happen. Not only could critical issues arise, but there could be unplanned absences of team members or work could be more complex than envisioned during refinement and planning. The Sprint Goal, selected Product Backlog Items, and plan for delivering the Increment should keep the existence of unknown unknowns in mind.

Scrum Masters are generally not involved in this process. However, a Scrum Master may help out. Since a Scrum Master is accountable for helping the team "focus on creating high-value Increments that meet the Definition of Done", "causing the removal of impediments to the Scrum Team's progress", and "helping employees and stakeholders understand and enact an empirical approach for complex work", the Scrum Master can work with the team to understand the implications of different choices or facilitate discussions between the Product Owner and stakeholders, the Product Owner and Developers, and/or the Developers and stakeholders. During Sprint Planning, a Scrum Master can also coach the team on effective planning techniques and help them craft achievable goals.

Answer 3

TL;DR

A variant of your question has been asked before. The underlying X/Y problem here is that your team is being asked to do both development and support, and it doesn't appear that anyone involved in the process (whether it's the Scrum Team or external stakeholders) is taking account of the fact that all work consumes capacity, and nothing can be done "for free."

Ultimately, that's the process problem you need to solve for. The rest is just semantics and renegotiation of working agreements within the Scrum Team and with stakeholders.

The Sprint Goal

Scrum is a framework that is based on the idea that each Sprint delivers some potentially-shippable increment of work. That work is prioritized by the Product Owner, but selected for inclusion by the Developers during Sprint Planning.

In addition, a Sprint Goal is defined during Sprint Planning. The goal of a Sprint is never to "do all the things." Rather, the goal is to meet the Sprint Goal. So, any work that isn't related to the Sprint Goal is inherently suspect, and any work that puts the Sprint Goal at risk may require an early termination of the Sprint and a return to Sprint Planning.

Reduce Planned Capacity or Fix Your Planning Processes

Since you state that you routinely have work "injected" into your Sprints from outside the team (which is actually not permissible if you're following the formal framework) then you need to do a couple of things.

1. Make the cost of unplanned work visible. "No invisible work, ever!"℠

   There's no such thing as a free lunch. Unplanned work consumes capacity, costs money, and depletes resources. If you're allowing "injection" of work without any sort of triage or process transparency into the disruption this causes to the Sprint Goal, then the Scrum Team is failing to communicate effectively with stakeholders.

2. Consider the Sprint Goal when evaluating unplanned work.

   If the additional work can be absorbed without endangering the Sprint Goal by changing the scope of the goal or specific Product Backlog items, this can be done as a collaborative exercise between the Developers and Product Owner. The PO owns the Product Backlog, but only the Developers can modify the Sprint Backlog. So, while the Scrum Guide says scope can be renegotiated with the Product Owner, it must still be done in collaboration with the Developers since they will need to adjust the Sprint Backlog to accommodate the new scope and/or plan.

3. Use early Sprint termination when warranted.

   If the work can't be absorbed without preventing the Sprint Goal from being met or ignoring the Definition of Done, then the Product Owner must call for an early termination and a return to Sprint Planning. The cost of doing this should be made crystal clear to the stakeholders.

4. Reduce capacity to create sufficient slack, and review working agreements with stakeholders.

   If unplanned or unplannable work is a consistent problem for the Scrum Team, either the working agreements with the stakeholders need to be adjusted so that support work is scheduled for future Sprints (just like any other new Product Backlog item), or the Scrum Team should simply reduce its planned capacity to account for the volume of unplanned work that routinely crops up.

   Think of it this way. If the team is consistently dedicating 25-50% of its available capacity to unplanned work, then the team should simply leave that percentage of capacity as available slack. If you use story points and routinely plan 30 story points per Sprint, then the Developers should simply stop accepting more than 15 story points per Sprint into Sprint Planning. The remaining capacity is slack available for unplanned work, and this makes the cost of unplanned work visible to stakeholders, helps create transparency around release planning, and even helps the Product Owner communicate expected lead times more clearly to stakeholders. Everyone except the people who think invisible work is free comes out a winner!

5. Admit that the process is somehow broken, then fix it.

   Either the Definition of Done needs refinement, QA and bug testing needs to be moved into the Sprint instead of being a post facto activity, your CI/CD process needs to be revisited, or the relative value of these unplanned activities need to be carefully reviewed to determine whether the cost/benefit of disrupting the Scrum cadence is actually warranted.

It's not that Scrum doesn't have answers to the issues you're facing. It's just that there's no zero-cost "fix" for the problem; all possible solutions come at some cost. Your job as a Scrum Master or agile coach is to ensure that everyone involved understands the framework and its defined events, cycles, and inspection points. Routinely breaking the framework's planning and delivery cadence ultimately reduces project predictability, and that has to be made crystal clear.

The defined inspect-and-adapt cycles built into the framework are there for a reason. If the business is choosing to bypass them for whatever reason, then they need to do so in a deliberate and informed way, with full acceptance of the project risk they are introducing.

Answer 4

First of all in support/maintenance projects it is quite often to have some issues or production bug at higher priority over the new improvements.

But if injection of new work based on new requirements by Product Owners in devleopment project in happening frequently in between the sprint, it should be discouraged and discussed. Development work can be prioritized in backlog for next sprint based on priorities. If each sprint is added with some new story that will result in breaking tempo & cadence by extra efforts required in descoping some work, estimating new work, finding dependencies & communicating within or external teams and some previously unexpected results.

In most scenario I see, production issues, security vulnerablity takes precence over most of work in progress and Product owner has nothing to contribute here and Dev+Ops teams decide and communicate the severity and urgency of impact.

As a scrum master you should try to inform anti patterns to PO's, sensitize them of effects of frequent change in sprint scope and also improve process based on Retro findings.