If a feature to be developed in a sprint is blocked due to a dependency, how do you handle it as a PO?
-
Make sure the dependency is resolved?– nvoigtOct 8, 2019 at 4:43
-
1This is currently too broad, and is missing important context. Why is the feature blocked? Why can't the team unblock it? Is the feature essential to your Sprint Goal? What's the impact of not completing the feature this Sprint vs. other work that's completable?– Todd A. Jacobs ♦Oct 8, 2019 at 13:15
2 Answers
It depends on how and why it was blocked.
If it was known that there was an unresolved dependency going into the Sprint, I would consider not bringing it into the Sprint to begin with. Minimally, the conversation should be had to determine what the risks are for planning on completing a given piece of work with a dependency that may or may not be met.
However, not all dependencies are necessarily known at the time of Sprint planning. In this case, the right thing to do would be to ensure that the team is escalating this issue. If work is impeded, the Development Team should raise this to the Scrum Master and Product Owner immediately. How it's handled depends on what the dependency is, exactly, and what needs to be done to get block removed. It's going to be a collaborative effort between the Product Owner, Development Team, and Scrum Master to resolve the impediment facing the team.
If the Scrum team is unable to resolve the block within themselves (don't have the necessary resources etc) it needs to be raised to the Product Owner immediately.
At the Sprint retro, it should be documented why and how this block arose in the first place, and how it will be avoided next time (more detailed conceptions during Product Backlog Refinement or adding the necessary resources to the Scrum team). The key to Scrum is autonomy, it is up to the Product Owner to ensure that autonomy.