Problems with PO and Reviews
Hi, all.
When our PO, will validate one history (not in a review ceremony), during the sprint, He is rejecting it and adding some rules or changes that did not write in a history before.
At the begging that action, our team did some changes because we believed that was punctual. But it turned on a repetitive thing.
At the last retrospective the team said to PO all this thing but didn’t work.
We will start to decline new changes in the validation step. Is it the better thing to do?
Our PO also talk a lot about technical and UX things with the argument that he wants to know how we work, But, in fact, He are doing our work. He already created a user flow for our UX and a structure of Mongo DB.
We already said to him, please stop trying to make our job, pay attention with the product, the backlog, the direction of the product the OKR/KPIs.
But it is not working.
What jumps out at me in the above scenario is this:
Why doesn't your PO trust the Development Team?
Perhaps the PO's response may give you some insight into current behaviors.
He is rejecting it and adding some rules or changes that did not write in a history before.
He can make whatever changes he wants to items on the Product Backlog, but not items on the Sprint Backlog. The Sprint Backlog wholly belongs to the Development Team.
We will start to decline new changes in the validation step. Is it the better thing to do?
It might be better for the Scrum Master to remind him that he simply isn’t in a position to change the Development Team’s Sprint Backlog. It is their plan and forecast of work for meeting their Sprint Goal commitment.
If he has an idea on how they might better achieve the Sprint Goal, he can approach them with suggestions in a collaborative spirit. The Development Team should reciprocate and, by working with him, make their own informed decision on what to do.
My initial thought on this is the the Sprint Backlog was created based on a shared understanding of what each story means. That is how it progresses. If there are new requirements based on what is built, those become new stories in the Product Backlog and can be considered for a future sprint.
It might be good to remind the Product Owner that a Sprint produces a "potentially releasable increment" not a "completely releasable increment". It is up to the Product Owner to decide when enough increments combined are ready to be released. So they add new requirements to the Product Backlog and order them high. Then after those Product Backlog Items are done they can release the increment that he feels is ready.