The team is working with a user story and they are stuck on some technical issues and unable to resolve them. This story is committed for the current Sprint. Shall I put this story on hold after discussing it with the Product Owner?


This story is committed for the current sprint.

Teams should not commit to completion of Product Backlog Items for a Sprint. The team's Sprint Backlog is a forecast, based on the team's past performance and looking forward for the expected capacity of the team. The idea of commitment only appears in respect to individuals committing to achieving the goals of the Scrum Team.

For a given Sprint, the team's commitment should be to the Sprint Goal. Ideally, there is alignment between the Sprint Goal and the Sprint Backlog. If the entire Sprint Backlog is necessary to be completed to achieve the Sprint Goal, there is risk. Ideally, there are items in the Sprint Backlog that the team feels that they have confidence in completing, but are not necessary for the accomplishment of the Sprint Goal by the end of the Sprint timebox.

Shall I put this story on hold after discussing it with the Product Owner?

Does the failure to complete the work jeopardize the Sprint Goal?

If the Sprint Goal is in jeopardy, then yes - this needs to be raised with the Product Owner immediately. The Product Owner needs to work with the Development Team to understand opportunities and trade-offs, and then work with stakeholders to manage expectations.

If the Sprint Goal is not in jeopardy, the Development Team should focus on the Sprint Goal first. This can be raised with the Product Owner to let them know, but the main expectation of stakeholders outside of the Scrum Team should be on receiving the outcomes of the Sprint Goal and not on particular units of work.

  • 1
    +1 for a succinct answer, and for noting that "commitment" has been removed from the Scrum Guide in favor of "forecast." I'd just note for the OP that Sprint Planning provides forecasts and estimates related to a Sprint Goal, not a money-back guarantee that X amount of work units will be completed within the time box.
    – Todd A. Jacobs
    Aug 1 '19 at 13:08

Blocker Assessment

There are two ways to look at this:

  1. Temporarily blocked stories that can be resolved eventually within the current Sprint.
  2. Unresolvable blockers that can't be successfully addressed within the current Sprint.

Resolvable blockers can be placed on hold temporarily, but in general it's better for the Scrum Team to swarm over unblocking a story that's on the critical path than to put it to the side. Circumstances and particulars will certainly vary, though.

Temporarily Blocked Stories

Temporarily blocked stories should be evaluated to see if:

  • The story is essential to the Sprint Goal.

    In Scrum, each Sprint must have a unifying Sprint Goal. The objective of each Sprint is to complete the Sprint Goal, not just "work on lots of stories." So, if a user story is blocked, but the Sprint Goal can be completed without completing this particular user story, then the team should take the story off the critical path for the Sprint. Depending on the story, it should either be discarded or placed back on the Product Backlog for the Product Owner to re-evaluate in the future.

  • The Scrum Team (including the Development Team, Scrum Master, and Product Owner) can unblock the story somehow.

    This may involve changing the scope of the user story, or identifying additional Sprint Backlog items necessary to complete the original story. Unblocking things often involves negotiation with stakeholders, end users, or external process owners as well as the Product Owner.

  • The blocked story can be put on hold temporarily within the Sprint.

    The Sprint Backlog belongs to the team, so its contents and ordering is up to the team. This can free up a work-in-progress slot for something that can be completed. However, it's very important that this technique isn't incorrectly used to create a multi-tasking situation or to cover up blockers that impact the Sprint Goal.

As a rule of thumb, stories should be worked on until completed rather than placed on hold. When a story is blocked, the whole team should collaborate to unblock the story. If a user story isn't important enough to throw the entire team's resources at resolving its blockers, then it's arguable that the story isn't important enough to the Sprint Goal to be on the Sprint Backlog in the first place!

Unresolvable Blockers

If a blocker can't be resolved within the current Sprint, then it needs to be carefully evaluated.

  • Stories that impact the Sprint Goal must be unblocked or revised.

    If the blocked story would impact the Sprint Goal, the Development Team must work with the Product Owner and Scrum Master to find a way to unblock the story. If it can't be unblocked as-is, the Scrum Team should revise the scope of the story or add additional Sprint Backlog items that allow the story to be completed in any way that doesn't jeopardize the Sprint Goal.

  • Blocked stories that don't affect the Sprint Goal should be removed from the Sprint.

    If the Sprint Goal can be met without this story, then it should be removed from the current Sprint. It can be discarded if it has no value, or the Product Owner can place it back on the Product Backlog for re-prioritization and re-planning in a future Sprint.

  • Blocked stories that would jeopardize the Sprint Goal should trigger a return to Sprint Planning.

    A user story that is essential to the Sprint Goal, and that can't be unblocked, revised, or otherwise modified to be completable within the current Sprint should trigger an adjustment to the Sprint Goal (when possible), or result in a Sprint Cancellation called by the Product Owner.

    The Scrum Team can then hold a Sprint Retrospective to identify process changes that need to take place, and then return to Sprint Planning. The team then identifies a new Sprint Goal and selects user stories to meet the goal that can be successfully completed within a single Sprint.

Product Backlog Items don't automatically roll over from Sprint to Sprint. So, Sprint Planning should ensure that all work selected from the Product Backlog relates to the current Sprint Goal and fits fully within the current Sprint.

Blockers that prevent progress towards the Sprint Goal are common enough that the Scrum framework provides mechanisms for dealing with them. As long as the Scrum Team is sure that the blockers can't be resolved, then it's up to the Scrum Master to provide the team with framework-appropriate options such as those described above.


Outside of the Sprint Goal decision(s) mentioned above, rather than putting this story on "Hold" you might use "Spike" instead.

Spike: A task aimed at answering a question or gathering information, rather than at producing shippable product. Sometimes a user story is generated that cannot be well estimated until the development team does some actual work to resolve a technical question or a design problem. The solution is to create a “spike,” which is some work whose purpose is to provide the answer or solution.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

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