What to do with unexpectedly blocked story in scrum?

Question

We have a low-pointed story which was dev-complete but, during testing, revealed a problem. In investigating the problem it was discovered that an external party will be required to deliver a fix. The external party will not deliver that fix before the end of the Sprint. Our Story is therefore blocked until the external party delivers their fix.

1. Should the Story remain where it is on the Scrum board at the next Sprint Planning or should it be dropped back into the Product Backlog?
2. If neither option in #1 is a good approach, what should be done?

Answer 1

With the required third party fix, you now effectively have a precondition for your story (that you assumed would be present from the start, but it turned out it wasn't).

You should put the story back into the backlog at the end of the sprint. It's not done. Whether you put it into a next sprint depends on your team's rules, but I would not do it unless the precondition is checked and validated before the start of the sprint.

A sprint should be filled with items so that the team thinks it can deliver that amount at the end of the sprint. If it's unclear whether a precondition can be fulfilled during the sprint, it should not even be a topic in the planning meeting, other than saying "preconditions not available? Okay, NEXT". A sprint should only be filled with items the team can deliver.

As always, exceptions may apply. A new backlog item for the next sprint might be "check out if the bug is still not fixed in their 1.2.3 release that comes out on tuesday". That can be done, even though the "done" result of the story might be "it's still buggy, we cannot proceed with the original story next sprint".

Answer 2

This is a great question and opportunity to learn! Yes, put the Blocked Story into the Product Backlog if you have a similar sized replacement and at the next Retrospective discuss:

What does this say about our Estimation and Definition of Ready?

If this story becomes unblocked before the end of the Sprint can it and/or should it be completed before the replacement story?

Also, with Kanban, you can insert a "blocked box" in your each WIP column (the blocked item should not count towards your WIP #'s) and this story would automatically be the highest priority item when it becomes unblocked.

Answer 3

I would also aver that this sort of thing should somehow be tracked by the team as "externally delayed." (Regardless of the "scrum name" for this notion.) Each and every(!) time the team loops around to plan its next "sprint," it should explicitly review the status of all of these items, to call management attention to the matter (and to the project-wide implications of it). Don't just give it "passing mention" in your project report – to someone [else], this is an action item.

Management needs to know – and, to know timely – that this sort of thing is happening, and especially if it's happening repeatedly. Consider it your team's duty to notify them and to keep them apprised.

"Here's why."

In my view, these represent functional dependencies that exist between "the project that your team is working on" and "other projects that you have nothing to do with." These are what determines "the critical path" at an organization or even enterprise level. They could easily represent deployment and/or operational issues when your project "goes live." While these are not per se "your concern," they must be explicitly recognized and tracked both within your project and [far?] above it.