Product Backlog Refinement

No. The reason for backlog refinement is so the PO can plan for future increments and releases.

When an item from the Product Backlog is committed to a sprint and worked on, it doesn't need to be groomed or refined during backlog grooming. It is in the sprint and any clarification that is needed by the dev team should be taken up with the PO in real time.

Ideally, No - but has to be in case-by-case scenario - as Product Backlog includes Sprint Backlog too. Grooming ideally involves all product backlog items that are not in the current sprint.

Sprint backlog is well planned and refined in the sprint planning. And if there is any need arises where sprint backlog item needs to be refined for example additional information has been found that requires changes that are not envisioned in the sprint planning - those needs to be informed ASAP to the PO and/or the team in the stand-ups.

The PO and the team can re-negotiate the current sprint backlog item with new information with a possible solutions like

a) Accepted by PO and the Team, with possible risk to the current sprint
b) Accepted AS-IS by PO and the team, with additional backlog item added to deal with the new information.
c) Removed from current sprint and bring back some thing else from product backlog - that can change the scope of the current sprint.

If either the Product Backlog or Sprint Backlog are insulated from change, waste is likely to be incurred due to delay and subsequent rework. Any developments in one should therefore be assessed for potential impact upon the other.

Change is managed through clear ownership of the Product Backlog (by the Product Owner) and the Sprint Backlog (by the Development Team), and the facilitation and guidance of the Scrum Master. Collaboration regarding undone work on either backlog should occur between them on an ongoing basis.

Ideally, No - but has to be in case-by-case scenario - as Product Backlog includes Sprint Backlog too.

No, the Product Backlog does not include the Sprint Backlog. They are separate artifacts. In Product Backlog Refinement the Product Backlog is refined, which means the items of the Product Backlog are reviewed, decomposed, enhanced etc. Speaking of Product Backlog Items here does not mean the Sprint Backlog is refined too, only because it contains Product Backlog Items as well. The wording can be misleading, and in my opinion the items should be called Sprint Backlog items as soon as they go from Product Backlog to Sprint Backlog to avoid confusion. Maybe this wording is on purpose to make it clear that we are still talking about the same items.

> No, the Product Backlog does not include the
> Sprint Backlog. They are separate artifacts.

The Product Backlog should reflect the entirety of undone work, including any undone work that is currently in the Sprint Backlog. PBI's should only leave the Product Backlog when the PO removes them or they have satisfied the Definition of Done.

Sometimes we talk about "returning" undone (and re-estimated) work to the Product Backlog from the Sprint Backlog, but this is not strictly correct...if it is undone, the work never actually left it.

No, I disagree. The Scrum guide states "Product Backlog items can be updated at any time by the Product Owner or at the Product Owner’s discretion." and "Only the Development Team can change its Sprint Backlog during a Sprint."
This leads to a contradiction if Sprint Backlog is a subset of Product Backlog.

"or at the Product Owner's discretion" is perhaps the key phrase here. Those PBI's that are currently in the Sprint Backlog, and which remain undone, are subject to potential replanning by the Development Team. They wholly own the Sprint Backlog and only they can change it.

The PO must of course provide approval for any changes to the PBI's and should in fact provide the necessary guidance for doing so.

I've just posted a blog on this subject:

"Counting Chickens: Undone Work in Scrum"

http://java.dzone.com/articles/counting-chickens-undone-work?mz=123873-…