If a feature to be developed in a sprint is blocked due to a dependency, how do you handle it as a PO?
closed as too broad by Todd A. Jacobs♦ Oct 10 at 3:29
Please edit the question to limit it to a specific problem with enough detail to identify an adequate answer. Avoid asking multiple distinct questions at once. See the How to Ask page for help clarifying this question. If this question can be reworded to fit the rules in the help center, please edit the question.
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.