Incoherence in the Scrum Guide?

Last post 02:39 am January 29, 2015
by Romuald Romek
8 replies
Author
Messages
02:22 am January 28, 2015

Hello,
I read through SG and I find there several things which might be incoherent for example:

The Scrum Master is a servant-leader for the Scrum Team.

In my opinion it should be:The Scrum Master is a servant-leader for the Dev Team, PO and Organisation.

Otherwise he is a servant to himself which is unlogical.

On the other side this is not coherent with further description of this section which describes his service to Dev Team, Po and Organisation.

This is even untrue when he is the developer also as he serves to himself but in as a developer he has a separate role so it contradicts either.

Let me know your thoughts.

Cheers,
Romek

07:22 am January 28, 2015

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

07:52 am January 28, 2015

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

08:39 am January 28, 2015

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.

08:55 am January 28, 2015

> 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.

09:19 am January 28, 2015

> ...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.

10:20 am January 28, 2015

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

10:49 am January 28, 2015

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 ;)

02:39 am January 29, 2015

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