The sprint backlog is frozen when the sprint planning is done ?
I plan to try the assessement I this weekend but i fell on this curious sentence about the freeze of the sprint backlog in "The Scrum Master training Manual" which makes me wonder ....
page 72 :
"The sprint backlog is frozen when the Sprint Planning is done, and no one can change it for any reason. "
Which is the exact opposite of what we can found in the "Scrum guide"
page 14 :
"The Development Team modifies the Sprint Backlog throughout the Sprint, and the Sprint Backlog emerges during the Sprint."
I tend to think the "Scrum Master training" is wrong because of common sense (and by googeling such a thing that ""sprint backlog frozen" which only gives 3 results containing the book itself ) .
As i'm not a native english speaker i may have missed something.
At some point i thought they wanted to talk about the product backlog items the team selected to put into the sprint backlog (let's freeze these ones in the product backlog, it's convenient fort the burndown charts for example)
but even that makes no sense to me because :
- product backlog grooming can be done anytime by the product owner/stakeholders/ the team
- sprint backlog are modified continuously by the team
- the Development team and the product owner can speak to each other anytime durint a sprint when the team asks for it.
So ... Do you have an idea of what they meant to say ?
When you take open assesment it says that there's nothing like 'frozen sprint" have a look at this sample question.
The Development Team should not be interrupted during the Sprint. The Sprint Goal should remain intact. These are conditions that foster creativity, quality and productivity. Based on this, which of the following is false?
Correct answer: B)
You chose: D)
Note: This question displayed answer options in random order when taking this test.
The Product Owner can help clarify or optimize the Sprint when asked by the Development Team.
*Missed correct answer 's: *
B) The Sprint Backlog and its contents are fully formulated in the Sprint Planning meeting and do not change during the Sprint.
C) As a decomposition of the selected Product Backlog Items, the Sprint Backlog changes and may grow as the work emerges.
*Incorrect answer is:*
D)The Development Team may work with the Product Owner to remove or add work if it finds it has more or less capacity than it expected.
Thanks for your answer.
Assuming the Assessment is hosted by scrum.org, i guess the guide set up the rules here (and there is no such thing as a frozen sprint backlog)
I'll ask the question to the authors of the training manual :)
I think the word frozen is very misleading here. When you talk to the authors, you may want to point that out. They offer a definition of frozen, however even this definition is wrong. Of course stories can be added or removed during the sprint, if the team learns it can achieve more or less, and if the sprint goal is not affected.
The statement “the Sprint Backlog is frozen” means that items (stories) in the Sprint Backlog cannot be added or removed during the Sprint. However, it might be necessary to get more information, justify, or clear some of the items during the Sprint, which should be done in the presence of the Product Owner. The detailed plan which is normally not complete at the end of the Sprint Planning will become more complete as the Sprint continues.
Ludwig is right, of course stories can be added or removed during the Sprint as long as the Sprint Goal isn't compromised.
The authors of the training manual referred to appear to come from DSDM rather than Scrum backgrounds. In this approach, it is considered reasonable to set certain tolerances within which change is allowed. For example, a Scrum Team working under DSDM project controls might only be allowed to change "could have" or "should have" requirements mid-timebox (i.e. mid-sprint). The "must have" requirements might be considered "frozen", at least in so far as they cannot be changed without the project falling into exception.
In this case, I suspect the authors might have experience of very low-tolerance DSDM implementations, where *nothing* is allowed to change scope-wise once a time-box has started. They may also have experience of earlier versions of Scrum that took a commitment-based view of Sprint Planning rather than one of forecasting.
The Scrum Master Training Manual you speak of is in no way affiliated with Scrum.org, and more importantly, because its information is often incorrect, I would recommend *against* using that as a study guide for PSM I.