What's the best practice in handling missed/dropped business cases through the sprint
I faced a situation that I am trying to search for the best way to handle it with minimal impact.
We are 2 teams working together, on a specific integration module, and after setting the expectations of this module and team A was about to finish his tasks.
Team B discovered a business scenario(which was missed in refinement and planning meetings) that would affect his current sprint scope, and team A should work on another integration path that would require effort from their side. We usually add any extra story popped up during the sprint to the PB and prioritize it, but this time it can't happen as it's a main scenario.
The PO (who is me) is the one blamed for skipping this business case, along with the QA team. I agree that it was a missing affected area and scenario that should be raised since the beginning. But I am currently stuck in how to handle this situation, how should the PO think and act to get the best out of the team and continue working.
And do you think that the PO should be the one to blame? After reading some blog posts, I realized that it's always said that acceptance is a collaborative work between PO and Dev team. Which is not the case or the process we follow, the PO is responsible of the acceptance, QA reviews the acceptance and the whole team discusses them along with the wireframes through refinement sessions and sprint planning. So I think that needs a mentality change to adapt that everyone should collaborate in writing acceptance and engage in features scope.
Appreciate your suggestions in handling such situations and if you had faced any similar one.
@Heba Mostafa, Why was it missed (how do we bring transparency over the situation)? What should be done, now that we know that we have missed something (how do we inspect and adapt)? What action makes the most sense right now, to get everyone together and focus on the outcomes?
That is how this should be handled. Hope this helps.
And do you think that the PO should be the one to blame?
Why should anyone be to blame, and who would do the blaming? Perhaps all are to blame for failing to recognize a shared learning opportunity.
You mentioned that everyone but Developers are to blame. As @Ian Mitchell said, why blame anyone and who is doing the blaming? Is it the Developers placing the blame? Why wouldn't the Developers share the blame since they are involved in the refinement process and could have identified this earlier? It sounds like this oversight was discovered based upon work being done and new information uncovered. Enter empiricism. As @Steve Matthew said, you should inspect and adapt accordingly.
There is no blame in the Scrum framework and there is no blame in a self-organizing, self-managing, cross functional team. This is only a failure if the team does not learn from it. It is exactly what @Ian Mitchell said. It is a shared learning opportunity.