Removing items from the sprint backlog due to emergency

Question

There is a lot of good debate here about changing the scope of a sprint backlog due to normal work circumstances; PO wants a new story, a dependency didn't materialize, etc.

In our case one of the team members had a family emergency that kept them away for almost half the sprint and the rest of the team could not pick up the work they had planned on doing. Should we replan the sprint backlog and remove the items they know cannot be completed? In planning the team fully owns the scope of upcoming sprint and we emphasize completing all Sprint items as a commitment.

I am curious how other teams have handled this situation.

Answer 1

In the situation you've provided where the team can no longer meet their expected plan for the sprint, then adjusting the plan is preferable. In short, as the Agile Manifesto says:

We value Responding to Change over Following a Plan.

No benefit is gained by pretending that the plan is still valid.

As for the last thing, there's some academic debate over if completing all stories is, in fact, an indicator of a successful sprint. There are two points in particular to consider on this:

1) Meeting the sprint goal and completing all stories are usually not the same thing. If they are, you may not be getting the most out of your sprints. If it appears that the sprint goal can not be met with the original plan, the question should be if the goal can be met another way or if a majority of the goal can be met with a new plan.

2) Your team may be over-committing and not effectively managing risk. This may be a great topic for the retrospective. Now, if you've got a team of 4 and they left at the beginning of the sprint, a 25% hit is a hard risk to plan for. You know the specifics of the situation better than I do.

Answer 2

How big is the team?

If one developer is absent for half a sprint, and you cannot pick up the slack of that, you have put too much into the sprint I guess. (This would be far more the case if it consist of 2 developers instead of 7 off course)

It happens a lot that in a 2-9 person team an illness occurs or unplanned holidays, so it would mean that you have this problem a lot?

Answer 3

Being clear that the decision of changing the Sprint backlog should belong only to the Development Team, this is what I think would be more correct.

I would say that if it is not something regular but ocasional, I would not act as if the plan is the same, but not remove items from the Sprint Backlog.

It might happen that any members of the Development Team discover that they are able to finish what they are working on earlier than expected and decide to make some progress about the uncompleted tasks. Other possible situations is that according to priorities the team decides to advance first in the tasks their partner is not going to be able to finish.

Anyway, we should remember that the whole Sprint Backlog belongs to the whole Development Teams. There are not task owners in the tasks of the Development Team, so really it is up to them how they manage the new situation and the incomplete tasks.

That said, the situation should be taken into account when reviewing the sprint and their metrics or reports so the Development Team does not charge like the false responsibility of not having been able to finish a forecast made at the beginning of the sprint when the really had a change in the team members number.

Answer 4

I think you should not change the Sprint backlog after it was created. Although exchanging stories is acceptable for some teams. Let the team decide if they think this is a good way to go or not.

we emphasize completing all Sprint items as a commitment

This is a huge problem. Scrum says the Sprint backlog is a forecast, not a commitment! Committing to something that has a high uncertainty is just stupid and leads to all kinds of issues. Actually the Scrum guide does not write about commitment anymore since 2013. It does expect team members to being committed to their own process and values.

Not completing a Sprint is not a sign of failure, but as a signal that there is something to learn, adapt and grow. It is good topic to discuss in the retrospective. The team should find a way how they want to handle people being sick, work being more complex than estimated, product owner wanting to re-prioritize mid-sprint.