Can I take out tasks during a Sprint if I am replacing them with more important tasks that those unstarted tasks would be dependent on?

Question

I have two tickets that have not yet started. A new ticket is being brought in that these tickets would be dependent on. Can I move them now into the next Sprint before this current Sprint has finished?

Answer 1

Yes, the Developers can add or remove work from the Sprint Backlog, as long as the Sprint Goal remains intact. However, there's no "next Sprint" to move the work into.

In the Scrum framework (as of November 2020), the Developers on a Scrum Team commit to a Sprint Goal at Sprint Planning. The Sprint Goal is not a body of work, such as Product Backlog Items or tasks. It is a statement that expresses the value to be delivered no later than the end of the Sprint. By doing some of the work toward the goal, the team may learn more about the remainder of the work needed to achieve the goal, including that some work was missing or some work was unnecessary. The Developers manage the Sprint Backlog, including adding and removing items, to ensure stakeholders have visibility of the team's progress. External changes, as demands from key stakeholders change, can also impact the scope of the work, and the team may not be able to wait until a Sprint Review and Sprint Planning to consider this work. Changes that impact the Sprint Goal or the team's ability to meet the Sprint Goal require collaboration between the Developers and the Product Owner, perhaps with facilitation from the Scrum Master. If the changes make the Sprint Goal obsolete, the Product Owner may cancel the Sprint.

Generally, the value-oriented and goal-based planning approach is more consistent with the Manifesto for Agile Software Development and working in a complex domain. One of the principles of Agile Software Development is "responding to change over following a plan". Planning and committing to units of work doesn't give the team flexibility when determining new ways to help stakeholders achieve their goals.

Answer 2

Yes you can do this, however there are certain implications.

If the change you are proposing means the sprint goal is no longer valid then you may need to consider either:

• Replanning the sprint (informing stakeholders of any changes)
• Cancelling the sprint and starting a new one

Neither of these options is desirable and we typically want to avoid this kind of situation.

I would strongly advise you discuss what has happened at your next retrospective. Try and work out what went wrong and how you can potentially avoid a repeat.

It would also be worth discussing how you have dependencies between backlog items. Again, this is something that we avoid where possible.

Answer 3

TL;DR

I have two tickets that have not yet started. A new ticket is being brought in that these tickets would be dependent on. Can I move them now into the next Sprint before this current Sprint has finished?

Automatic carry-forwards of Product Backlog items and preplanning non-process work items for future Sprint Backlogs are not permitted within the current Scrum framework. The Developers can modify the current Sprint Backlog as needed to meet the current Sprint Goal, but work is never automatically carried forward between Sprints in Scrum.

Additionally, neither the Scrum Master nor the Developers can directly modify the Product Backlog without an explicit delegation of responsibility from the Product Owner. Even then, the Product Owner still remains the sole role accountable for the Product Backlog artifact.

If you're doing something other than Scrum, the answer may be different, but you probably still shouldn't do it for the same reasons it's prohibited in Scrum. If anyone has a similar use case using a different framework, they should open a new-but-linked question specific to that framework.

Analysis and Recommendations

If you're following Scrum and not some other random framework that just happens to co-opt the term "Sprint" then the following applies.

CodeGnome's Scrum Tautology says: "Always remember that the goal of a Sprint isn't to complete lots of backlog items. The goal of a Sprint is to deliver the Sprint Goal." (Jacobs, 2018).

Developers can add or subtract work from the Sprint Backlog as needed to meet the Sprint Goal, but if you have a Sprint Goal that's dependent on the backlog item you're swapping out then you have to ensure that doing so will not impact the Sprint Goal. If it will, then you must renegotiate scope with the Product Owner (PO) or request that the PO call for an early termination and a return to Sprint Planning.

Furthermore, Scrum is based on time-boxed iterations and work is never automatically carried forward. The Scrum Guide (Schwaber, K. and Sutherland, J., 2020. § Artifacts §§ Increments §§§ Commitment: Definition of Done, para. 3) has done away with any ambiguity on this issue. Any work that is incomplete at the end of a Sprint is "not done," and returned to the Product Backlog for re-prioritization, refinement, and re-planning should it be relevant to some future Sprint Goal.

Pre-Planning Future Sprints is Muda Type II Waste

While teams often focus their refinement activities on Product Backlog items likely to be in scope for an upcoming Sprint, the emergent design and just-in-time planning a the heart of Scrum means that actively planning a future Sprint before the end of the current Sprint is an anti-pattern that works against the agile principle of embracing change and enabling rapid pivots. In other words, you can't know everything you need to know about the goals and Sprint Plan needed to build the Increments of a future Sprint until Sprint Planning. That makes pre-planning your future plans a potentially wasted effort—specifically type II muda—and a one of the core agile principles is to maximize the work not done.

Uncovered Dependencies

If you have uncovered new dependencies that won't fit within your current Sprint, then you certainly should adjust your Sprint Backlog. You may need to modify the Developers' critical path to the Sprint Goal, trim scope on backlog items or the Sprint Goal (without reducing quality) in collaboration with the Product Owner, or even abandon the current Sprint if you can't sufficiently modify the Sprint Goal or the Increment(s) to be delivered within the Definition of Done.

Uncovering dependencies is a feature of Scrum. Not everything is known up front, which is why Scrum has various inflection points and inspect-and-adapt events—and even an escape hatch for the current Sprint!—so that the team can fully embrace necessary change. However, unless you left sufficient slack in your current Sprint to complete both the predicate work and the planned work, or the original work item was a stretch goal or bonus work that wasn't directly tied to your Sprint Goal, then you won't be able to meet your originally-defined Sprint Goal if you remove one of its dependencies.

Ultimately, those are the questions you really need to be asking:

1. Is the work being replaced essential to our Sprint Goal?
2. If not, why was it included in the Sprint in the first place?
3. If it is, how will we achieve the Sprint Goal within our Definition of Done without completing the replaced backlog item?

As a rule of thumb, work that's not tied to the Sprint Goal is typically made up of chores, recurring tasks, story spikes meant to create validated learning for future Sprints, or stretch goals. Sometimes you can skip or defer such things in exchange for project tech debt or a temporary reduction in progress towards the Product Goal, but most of the time you'll find that the work shouldn't have been included in the Sprint in the first place because it was unrelated to the Sprint Goal or the team's ongoing processes. If that's the case, you have some good grist for the mill during your next Sprint Retrospective.

Leverage Scrum's Kaizen Event: The Sprint Retrospective

From a continuous improvement perspective, the whole Scrum Team should re-evaluate:

1. how work is being selected from the Product Backlog;
2. how the team is ensuring sufficient slack for unforeseen issues within the Sprint Backlog; and
3. how much INVEST decomposition needs to be done during Backlog Refinement and Sprint Planning to avoid taking on backlog items that have dependencies that could have been identified with some additional planning or a story spike in a previous Sprint to assist with planning and estimation when this backlog item comes into scope as part of a Sprint Goal.

In many cases, deferring story spikes, stretch goals, or non-essential chores can free up slack for unexpected work. That work still has to be done sometime, but if it's not directly tied to the current Sprint Goal then it doesn't have to be done now. That's the type of work you can swap out. Anything tied to the current Sprint Goal should generally not be removed from scope or returned to the Product Backlog without a much more nuanced discussion about the impact to the project.

As a one-off, this type of problem is inevitable in any complex project. However, if you're facing this type of challenge regularly, there's an underlying problem with your team's tracking of Product Goals, Sprint Goals, Sprint Planning, and estimation process that needs to be re-evaluated within the context of a correctly-implemented Sprint Goal:

The Sprint Goal...creates coherence and focus, encouraging the Scrum Team to work together rather than on separate initiatives.

There may be other issues, but that lack of central coherence on a singular Sprint Goal delivering an Increment of a singular Product Goal is most likely why your question is even a question in the first place. A properly-functioning Scrum Team should never be working on fungible work untethered from a measurable goal for the Sprint. How you meet the goal is certainly negotiable, but having multiple goals for each Sprint or work silos that would allow for swapping out goal-oriented work without impacting the Sprint Goal is a "process smell" that should be examined carefully.

Cancel Sprints with Obsolete or Unachievable Sprint Goals

You should inspect your processes no later than the Sprint Retrospective if the Sprint Goal can still be met given negotiated changes in scope to the selected Product Backlog items for the Sprint. However, you should do this immeditaely if the Developers and the Product Owner can't find a way to change the Sprint Backlog without making the current Sprint Goal obsolete.

A Sprint could be cancelled if the Sprint Goal becomes obsolete. Only the Product Owner has the authority to cancel the Sprint.

If you can't meet the Sprint Goal without reducing quality or renegotiating the scope of the Product Backlog items selected for the Sprint, this aligns with the agile principles of "failing fast" to avoid sunk costs and "embracing change." It creates a visible cost to the project, though, so it shouldn't be done lightly. However, that visibility and process transparency is part of the value that agile frameworks provide when done right. Such frameworks don't guarantee success; they just make process problems visible so that the Scrum Team or the organization can address them instead of creating "invisible work" to fix ongoing process problems.

In other words, don't keep stepping over a broken step on your stairwell. When you find a broken step in your process, true agility demands the courage to surface it, make it fully visible to everyone, and then collectively fix the real problem at its source rather than just treating the symptoms.

Answer 4

Of course you can but that would be wrong. It shows that you don't plan correctly. If you change the task list in a sprint while the sprint is running,

1. it will ruin all the velocity calculations
2. it will cause inefficiency
3. it will make sync work within the team inevitable

So, a sprint is to be started and finished with the same tasks. If you are facing this issue a lot, you should move to Kanban or Scrumban.