Question (not refined Product Backlog, Sprint planning)?

If the Product Backlog is not in a fit state for Sprint Planning, then the Sprint cannot commence. Since a Sprint is a container for the other Scrum events, this means that those events cannot be held at all.

What the team need to do is to refine the Product Backlog so that it is fit for purpose and a Sprint can start. This is more or less the "option A" you refer to, but it isn't really a matter of postponing Sprint Planning in particular. The fact is that no Scrum events at all can occur until then.

Hi Mehdi,
Q1: From the perspective of an Agile Coach, it is important to let the team fail here, so they will learn more likely than if you save them from failing and give them the chance to wait and prepare. Especially the Product Owner, who is accountable for backlog management, has to see during the sprint planning and the sprint how much waste he generates by not doing his job. The Coach should mainly observe. Then in the retrospective you can take all these observations and improve for the next sprint. A whole sprint seems like a big investion just to learn something, but the Product Owner will not come to a planning without a well prepared backlog again. I guess this is a combination of B and C.

Q2: We use a DoD, which is really important. I know some teams use an explicit DoR, however for us a PBI is ready if the team is able to estimate it, so we do not have this definition explicitly. I think it is hard to write it down specifically, but the INVEST criteria give you an orientation (independent, negotiable, valuable, estimable, small, testable).

Q1 - C
If you try to plan what is not ready, this can repeat itself.
Since you mention there are other PBIs in ready state, those should be taken to the sprint.

Hi Ian,

refer to scrum guide, new Sprint starts immediately after the conclusion of previous sprint.

Would Option B is likely the more appropriate approach to start the next sprint where the team will adjust and refine the spite backlog ?

With 6 years hindsight I’d go for option C.

A) We postpone the Planning meeting until we get first clarity for the top PBI in an extra refinement session because these are the most valuable Items and are important to be implemented first.

B) we keep the sprint planning meeting as planned and the Dev. team forcast roughly despite these ambiguities; and they adjust the scope (committed work) if necessary later during sprint with PO agreement

C) to remark such PBI on the top of Product Backlog list as "not ready" and ignore them for the current sprint . The dev. team pulls only PBI which are ready.

I think it can be situational , and as per me would go in this order - 

1. Choose option C and take this PBI into next sprint when refined.

2. Continue planning for other PBIs and if time box for planning still allows then will continue to refine this important PBI.

3. Choose A - Only in worst situation when no value can be delivered in a Sprint without implementing these unrefined PBIs. But as @Ian mentioned no further events can take place until then.