Skip to main content

Sprint Backlog: "frozen" or emerging.

Last post 01:40 am September 17, 2016 by Ian Mitchell
12 replies
12:58 pm September 14, 2016

Hello, Scrum Masters!

I am preparing to pass my PSM I assessment. Today, during reading Scrum Guide (yet again) and Scrum Master Training Manual I have found a little discrepancy (well, I think so) regarding Sprint Backlog.

In Scrum Guide it is said:

The Development Team modifies the Sprint Backlog throughout the Sprint, and the Sprint Backlog EMERGES during the Sprint.

While Scrum Master Training Manual says:
"The Sprint Backlog is frozen after the Sprint Planning..." "The statement “the Sprint Backlog is frozen” means that items (stories) in the Sprint Backlog cannot be added or removed during the Sprint."

So which is right? Does Sprint backlog should be static or dynamic? Or does the above is same and I simply didn't get that?

Looking forward to your help.

Best regards,
Anton.



02:36 pm September 14, 2016

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


04:59 pm September 14, 2016

@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?


05:30 pm September 14, 2016

Thank you, Luis!


05:40 pm September 14, 2016

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!


08:06 am September 15, 2016

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.


08:29 am September 15, 2016

Thank you, Olivier! That helps a lot.

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


08:41 am September 15, 2016

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?


02:39 pm September 15, 2016

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.


04:48 pm September 15, 2016

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.


05:06 pm September 15, 2016

Thank you once again, Timothy!

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


02:03 pm September 16, 2016

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.


01:40 am September 17, 2016

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


By posting on our forums you are agreeing to our Terms of Use.

Please note that the first and last name from your Scrum.org member profile will be displayed next to any topic or comment you post on the forums. For privacy concerns, we cannot allow you to post email addresses. All user-submitted content on our Forums may be subject to deletion if it is found to be in violation of our Terms of Use. Scrum.org does not endorse user-submitted content or the content of links to any third-party websites.

Terms of Use

Scrum.org may, at its discretion, remove any post that it deems unsuitable for these forums. Unsuitable post content includes, but is not limited to, Scrum.org Professional-level assessment questions and answers, profanity, insults, racism or sexually explicit content. Using our forum as a platform for the marketing and solicitation of products or services is also prohibited. Forum members who post content deemed unsuitable by Scrum.org may have their access revoked at any time, without warning. Scrum.org may, but is not obliged to, monitor submissions.