Incoherence in the Scrum Guide?

Hi Romek,
I had to smile when reading your post. If you want to be very pedantic, you are right. No part in the Scrum Guide describes how the SM serves himself. However a servant-leader can be part of the team he leads. He can give himself feedback for example.
There are some other minor incoherencies, for example "All incomplete Product Backlog Items are re-estimated and put back on the Product Backlog." How can you put a Product Backlog Item "back" on the Product Backlog? By definition it is already on the Product Backlog.
To improve the Scrum Guide, you can post your suggestions here:
https://scrumguide.uservoice.com/
Best,
Ludwig

Hello,
Yes sure it is a minor, funny thing I agree.
The scrum master role is not designed to give feedback to himself as defined. For me it does make sense to give feedback to himself and more important is to cooperate with organisation which is missing.

On the other hand the SG should be as transparent as it requires from Scrum Team to behave:-)
There are so many people involved that clean it from logical traps should be easy.
On the other hand what should be the answer to PSM exam questions if SG is incoherent.


The PBI if taken from PB is not longer on PB I believe - so in this case I would agree with wordin in SG.

Cheers,
Romek

Well, I can be pedantic too :)
Are you saying it is possible that a Product Backlog Item is not on the Product Backlog? What is your definition of "item"?
Is your definition of "member" similar? Can a team member exist who is not on the team?
In my logic that is not possible.
In addition, the PBIs are only selected, but never taken from the PB.

> The PBI if taken from PB is not longer on PB I believe - so in this case I would agree with wordin in SG

The Product Backlog should capture the totality of scope remaining for the completion of the Product. Items that have been planned into a Sprint Backlog and which are not yet Done therefore remain undone, and should still be accounted for on the Product Backlog.

"Returning" undone work from the Sprint Backlog to the Product Backlog is a useful expression. However it does not imply that the associated Product Backlog Items were ever removed. These items can only be removed from the Product Backlog once the associated work has met the Definition of Done to the Product Owner's satisfaction, or if the PO decides to retire them.

> ...Items that have been planned into a Sprint Backlog and which are not yet Done
> therefore remain undone, and should still be accounted for on the Product Backlog

Incidentally, this brings in certain considerations when Scrum is applied at scale. Multiple Development Teams can draw work from the same Product Backlog, Since the work that one team has planned into a Sprint must remain on the Product Backlog until it is completed, it is theoretically possible for another team to plan the same PBI's into their own Sprint.

It is up to the Product Owner to manage this risk, and to ensure that the PBI's negotiated with each Development Team are appropriate and do not amount to the unnecessary duplication of work.

Bear in mind however that a PO may actually *want* the same PBI's to be actioned simultaneously by multiple teams. This could allow the PO to select from a choice of potentially releasable increments, although the waste incurred through duplicated effort would need to be justified in terms of product or market risk.

Hi Ludwig,

I say that when PBI is moved to SBI it does not exist on PB any more - what is the sense to keep it there if we are working on this?

Cheers,
Romek

Scrum Guide does not use the word Sprint Backlog Item, the items on the Sprint Backlog are still called Product Backlog Items, so set theory says Sprint Backlog must be part of Product Backlog.
But I doubt that this discussion brings us any closer to improving the profession of software development ;)

But it brings us mabe to betrter understand scrum guide. Thank you.