What should/can the Scrum master help, when the scrum team complaint other others?

Hello Luhua,

Personally, I do not think there is anything wrong with the Product Owner changing their mind but if it is during the sprint regarding items already in the Product Backlog, then that would greatly jeopardise the sprint goal and I can understand why members of the development team may not be happy. But even as of that, based on consumer or stakeholder feedback, a PBI item may no longer be required so rather than implement something of no value, then it should be removed from the PB or the Sprint Backlog.

Now, this is me just speculating but if it is deeper than then I think the Scrum Master needs to sit with the Product Owner to try and understand why PBI's keep changing. It could be that the Product Owner is afraid to completely own the product, it could be a slow process of gathering feedback from stakeholders or customers, it could also be some organizational issues that are unknown at the moment. The SM should try and work with the PO the dev team and come up with actionable ways to remove this impediment. 

But the SM needs to ensure that it is done in a way to provide further rift which will erode trust but to foster the team's growth.

Do product owner and development team have shared definition of ready, so the development knows what to implement based on the information provided with the PBI? While there is always a certain amount of room for interpretation in those boundaries, actual changes to the boundaries themselves should not happen if possible.

Is the PO objecting to lack of domain knowledge or is he actually concerned that the Dev Team does not possess all the necessary skills to produce a Done increment?

Hi Steven and Julian,

Complaint from the development team is Product Owner cannot explain PBIs clearly but the Product Owner says the development team are lack of domain knowledge. requires a lot time to explain again and again and lose the trust. 

It's not unreasonable for a team to reserve 10% of their time during a Sprint for Product Backlog refinement. How much time is spent on refinement in this case, and is it comparatively excessive?

However much time is spent on understanding the Product Backlog, why is trust between Scrum Team members affected? 

Well, it sounds like what I have experienced in the last couple of months.

What happened was the most senior architect in the company (a developer in development team) left, dev team had a big hole in the knowledge of the system. There was knowledge transfer. Just the transferee was not able to catch up that quickly. 

Then dev team started complaining PBI was not clear enough that they had no idea what changes to make. The PO said the PBI was like it had been. The dev team just had no idea about the system so that they had no idea what changes to make however they played tricks to complain about the PBI. 

The resolution was 

- The company's CTO sit in the dev team to guide the on the system solution at very detailed level.

- PBI took an updated format, where the system changes are listed

The first one was the key as the knowledge hole was filled by the CTO.

The second one was a compromise to make everyone happy like, look, PBI are improving so not just dev team's issue and we are a team.....

Luhua, in your case, please find out what are behind the complaints then you can resolve it.

Opuada, thanks for your reply. need to work with the PO the dev team focus for actionable ways.

Ian, thanks for questions. the PBIs were not fully understood and the development team do not ask right questions in addition, the development need to share more knowledge. the team need to be open and respect others.  Scrum values need to be built in the team.

Software Developers, especially in the early stages of development will almost always lack the necessary domain knowledge. This is something that develops over time. Maybe the PO could find a way to confer more of his domain knowledge onto the developers? Additionally, I second Ian's comment on Backlog Refinement. In the end, that's the only way, PO and developers will gain a shared understanding.

Thanks Will and Julian,  

agree.  also an item for Sprint Retrospective for improvement.