In the current (2020) version of the Scrum Guide the word “commitment” is used with regards to the sprint goal – “Although the Sprint Goal is a commitment by the Developers, it provides flexibility in terms of the exact work needed to achieve it.”
So what should happen after the team and product owner agree on the goal for a sprint, create a sprint backlog and start the sprint … but then someone* tries to add something to the sprint? (*The “someone” could be the product owner, a manager, or it could be a critical production defect.)
The Scrum Guide doesn’t provide much in the way of guidance other than “If the work turns out to be different than they expected, they collaborate with the Product Owner to negotiate the scope of the Sprint Backlog within the Sprint without affecting the Sprint Goal.”
What does that negotiation look like? A colleague from a previous company, Kiryl Baranoshnik, wrote a post with some good suggestions but I have a slightly different set of suggestions. Like Kiryl’s post, I’ll break it into two parts: Immediate Action and Retrospection, but I’ve not had time (or the skill) to create my own infographic yet.
Immediate Action:
- Postpone it
The first decision should be whether the work really must be done in the current sprint – if it’s not important and urgent then it probably doesn’t deserve to jump the queue. The default answer should be to add it to the product backlog and only bring it into the sprint if it absolutely cannot wait.
If the product owner decides it must be done ASAP, then the team should follow their standard refinement practices, e.g. referring to their Definition of Ready and estimating the new story.
- Exchange it
A question that I have found to help focus the product owner on whether the new work really justifies disrupting the sprint is to ask “If we were to bring this new story into the sprint then we will remove the equivalent (estimated) size of work from the lowest priority items in the sprint backlog – is that ok?” This tends to make it clear that some of the originally planned work is unlikely to be done, which often has a knock-on impact on the product roadmap.
- Absorb it
If the team are confident they have the capacity to complete their sprint goal as well as the new request, then they can choose to bring the additional work into the sprint as is. The risk is that, despite their confidence, the team are unable to complete everything; this should be raised with the PO and discussed just the same as the team would do if a regular (uninterrupted) sprint was in jeopardy.
I put this option last as it can sometimes be more of a non-decision, e.g. because the team may feel pressure to accept the new work in addition to their plan or be overly optimistic. If it is the route taken then I strongly recommend the team make it clear that, even though they will try to absorb the additional work, it could put the lower priority sprint backlog items at risk. It’s always important to talk to the product owner if reality isn’t going as planned, but in this instance, I think it is especially important for the PO to be aware.
In summary, the three reactions to choose from are: “no, we’ll put it in the product backlog”, “yes but something has to make room”, or “yes we think we have room for it”.
Retrospection:
If the decision was either flavour of “yes” then the team and product owner should hold a retrospective to discuss the root cause (why did this work appear after sprint planning?) and how it impacted the sprint. I would recommend a retrospective even if the answer was “no” because the root cause question should still be addressed – why wasn’t the new request just added to the product backlog?
One other thing to discuss is how often these unplanned requests arise: if it becomes frequent then the team and product owner should discuss whether the sprint length is appropriate (if two-week sprints are frequently interrupted then maybe try one-week sprints), or if the nature of the incoming work is simply unpredictable (e.g. support teams tend to use kanban’s flow approach rather than sprints). There could be other causes, for example is the product owner able to say “no” to stakeholders (see Henrik Kniberg’s excellent “Agile Product Ownership in a Nutshell” video) but ultimately the aim of the retrospective is to identify the root cause(s) and experiments to try to address them.
Anti-patterns:
- Leaving room for emergencies
If the sprint interruptions happen frequently then there may be a temptation to leave some capacity unplanned, ready to insert the additional work. The reason I list this as an anti-pattern as it can hide the problem but also because it can give a distorted impression that the team is over-delivering. - Having one team member assigned to emergencies
A slight difference to the previous one, I’ve seen teams allocate one team member (often rotating the duty each sprint) as their “on-call” person; they plan the rest of the team’s sprint as normal but the selected individual works from an unplanned “to do” list. Again, this hides the problem of late-breaking unscheduled work. - Saying “yes” without being able to consider the impact
Teams that don’t feel they can say “no” or discuss how the additional work impacts their sprint plan aren’t really planning their sprints – if you can’t say “no” then saying “yes” has no meaning. Morale tends to be very low as the team has no control over their workload, which management often describe as “lacking engagement or ownership”.
This list could probably include a lot more anti-patterns, but please leave a comment if you’ve had success with these Immediate Actions or seen other ways to handle the mid-sprint request to add One More Thing.
