Sprint Backlog: "frozen" or emerging.

The correct answer is always in the Scrum Guide, that's where you have to look at.

"The Development Team modifies the Sprint Backlog throughout the Sprint, and the Sprint Backlog emerges during the Sprint. This emergence occurs as the Development Team works through the plan and learns more about the work needed to achieve the Sprint Goal."

@Luis - agreed

I would be wary of any Scrum source other than the Scrum Guide. I know of no "official" Scrum Master Training Guide.

The Sprint Backlog may evolve as needed during the sprint to achieve the Sprint Goal. That may require items either added or removed from the Sprint Backlog.

Ask yourself Anton, does "freezing" the Sprint Backlog sound agile (i.e. - flexible) to you?

Thank you, Luis!

Thank you for your reply, Timothy!

The moment a read about "frozen" sprint backlog I thought "this can't be right" and I just wanted to make clear to myself that I understood correctly.

This is actually the problem. Too many sources that claim to help to get ready for an assessment and then you end up with the "frozen backlog".

Thank you once again for clarification!

Idealy, the sprint goal doesn't change (frozen) and the set of selected User-stories doesn't change during the sprint. It helps the Dev Team to be really focus and this create commitment.

But the plan to build the increment (the decomposition in small tasks) will evolve a lot. This require courage to challenge the plan every day and this needs respect toward the strenghts and weakness of every team member.

Thank you, Olivier! That helps a lot.

But, we can take user-stories out if they become obsolete during the Sprint, right?

Anton, I have sought the quote you comment and if you allow me, I would like to open the door to reflection (I really do not know if it would be better another thread). Because seeing more context, most likely the term "frozen" is not the best, but I have understood what MPlaza means:

The Sprint Backlog is frozen after the Sprint Planning and the Development Team will focus on delivering an Increment of “Done” based on this plan. 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.

Both in blogs, articles, forums etc. I have always seen to refer to tasks (the elements resulting from the decomposition of PBIs) as part of the Sprint Backlog modifiable and the PBIs as fixed elements referring to the need to be focused.

I read by Nth time the Scrum Guide, and I really think both (PBI and tasks) are subject to change since the PBIs are part of Sprint Backlog. However, changing PBIs usually (always?) leads to the change in scope and therefore in this case it is necessary that the DT renegotiate with the PO.

How do you see?

From the Scrum Guide:

As new work is required, the Development Team adds it to the Sprint Backlog. As work is performed or completed, the estimated remaining work is updated. When elements of the plan are deemed unnecessary, they are removed. Only the Development Team can change its Sprint Backlog during a Sprint. The Sprint Backlog is a highly visible, real-time picture of the work that the Development Team plans to accomplish during the Sprint, and it belongs solely to the Development Team.

The statement from MPlaza is therefore incorrect, according to the Scrum Guide. The Sprint Backlog can indeed evolve as necessary (addition or removal of items) to allow the Development Team to deliver the Sprint Goal. As a matter of courtesy, the Development Team can consult with the Product Owner on items added or removed from the Sprint Backlog (transparency, respect).

The Scrum Guide makes it perfectly clear that the Sprint Backlog is owned and managed 100% by the Development Team. It is their plan to meet the Sprint Goal. As Olivier stated, the Sprint Goal is not modifiable. The plan to meet the Sprint Goal can certainly evolve throughout the sprint, and this may require the Development Team to adjust as needed the work required to meet it.

I don't think I am yet in place to assume anything about agile methods, because I have only started my studying SCRUM. But, I have experience in classical/cascade project management and based on it I can tell that even in more conservative (less agile) frameworks it is important for PM to know how to scopecrashing, i.e. playing with project scope in relation to budget and schedule. Sometimes some of the requirements can be dropped and there are multiple reasons to that. So even in non-agile environment you have to practice flexibility. That is why I thought that SCRUM should be even more fitted to that and also I have found a mismatch between that training manual and a Scrum Guide.

Well, I will stick with Scrum Guide version of Sprint Backlog after all the assessments are based on it.

Thank you once again, Timothy!

It is getting clearer and clearer to me. Thank you for the explanations with the reference to scrum values.

Thank you for the explanations with the reference to scrum values.

Technically, transparency is one of the 3 pillars of Scrum, and respect is one of the 5 Scrum values, but you are very welcome just the same.

"Openness" is one of the 5 Scrum values, and probably would also fit in this example.

> The moment a read about "frozen" sprint backlog I thought
> "this can't be right" and I just wanted to make clear to myself
> that I understood correctly.

Think of the Sprint Backlog as a forecast, or a plan, of what the Development Team expect to do in order to meet the Sprint Goal. Clearly that backlog ought to be revised if it helps the Goal to be better achieved. The Sprint Goal itself is sacrosanct, in so far as it provides a coherence for sprinting in the first place.