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.

  • dev. team can inform this to SM as this situation is affecting sprint, and SM in turn can discuss with PO. Usually, when planned user stories are not projected to be completed, better to prioritise remaining work for the current sprint and try to bring as much value as possible by completing other planned user stories, in the current sprint itself. Also, during sprint retrospective meeting, team can decide course of action if similar situation arise in future. Commented Sep 13, 2017 at 5:01
  • The Scrum Guide Sounds like a project manager acting as a Product Owner (wanting a new story). The Sprint Backlog is a forecast, not commitment. Commented Oct 3, 2017 at 17:50

4 Answers 4


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.

  • Can you recommend some reading on establishing good sprint goals? I've not found any description that I felt fits my team's circumstances. I agree that this does not seem like an over commitment problem. I am more worried about this leading to the team removing stories for less extreme circumstances as a way to complete the sprint.
    – Sam
    Commented Sep 13, 2017 at 4:10

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?

  • The team is 3 developers plus some QA and content folks. Missing one of the developers for half the sprint is not a common occurrence so I don't think this is something we should try to account for in planning.
    – Sam
    Commented Sep 13, 2017 at 3:58
  • When it consist of 3 developers, missing a developer for half a sprint is about a 15-20% decrease working hours for that sprint. If it is not that common, I would just treat it as "it happens sometimes" and explain why you didn't get the sprint goal this time. If this happens regularly, it should be something that comes up during a retrospective or so and then you can address the problem there.
    – Bauwens
    Commented Sep 13, 2017 at 7:12

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.


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.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.