Sprint Backlog - Developers have realized that they have over-committed themselves .....
Hello together. I am preparing myself for the PSM1 and have to rise this question because I can not really "understand" this.
Exam question & answer oprtions:
Q: The Developers have realized that they have over-committed themselves for the Sprint. How should
they review and adjust the work?
A: Yours Expected
a. They can get help from the Product Owner to adjust the Sprint Backlog.
b. They should ask the Product Owner to cancel the Sprint.
c. They can make any adjustments themselves, because they own the Sprint Backlog.
d. They shouldn't make any changes to the Sprint Backlog.
Explanation:" .....When you see that you can’t deliver all the items, the only consideration is to see which
items are the most important ones to deliver, and how you can revise the scope of the
existing items to deliver more value. To do so, Developers have to consult the Product
Owner.
Remember that the commitment is the Sprint Goal, not the scope that was initially defined
in the Sprint Backlog."
The last sentence containes the point of confusion. According the 2020 Scrum Guide "The Sprint Goal, the Product Backlog items selected for the Sprint, plus the plan for delivering them are together referred to as the Sprint Backlog" the number of selected items is the scope of, let´s say Sprint Sart / initial scope.
So, the Guide says this scope is part of the Sprint Planing´s result, but the explanation ignores / refuses this!
Is the number of selected items not part of the commitment or not???
The Sprint Planning produces three things: a Sprint Goal, a selection of Product Backlog Items (at least some of which are believed to be necessary to accomplish the Sprint Goal), and an initial plan for the team to achieve the Sprint Goal by getting one or more Product Backlog Items to Done. Together, these three things are the Sprint Backlog, so you could say that the Sprint Planning produces a single output - the Sprint Backlog. Personally, I find it more useful to focus on the three things independently, since it helps the team make sure that they have addressed all of the key points.
The only commitment that the team makes is to the Sprint Goal. Keep in mind that agile methods - of which Scrum is one - are about responding to change. By doing the work toward the Sprint Goal, the team may discover that they missed some work necessary to achieve it and would then add it to the Sprint Backlog. They may also find that some work they thought was necessary is not and their replanning could deprioritize that work.
The Daily Scrum gives the Developers the opportunity to come together for the purposes of replanning. But discovering more information about work - unplanned things that become necessary or planned things that become unnecessary - happen as part of the regular work. For the purposes of transparency, I tend to encourage that the team keep their Sprint Backlog up-to-date in near-real-time. Minimally, though, I would expect any replanning done at the Daily Scrum to be reflected in the Sprint Backlog.
C would be the correct answer. However, if the Developers think that the Sprint Goal is in jeopardy, then A becomes the answer, and B could be a possible outcome if the Sprint Goal is obsolete or there isn't a way to make a viable Sprint Goal.
You are focusing on a specific statement in the Scrum Guide. I have found that often leads to confusion because the guide is full of information. For example, in the section of the guide that describes the Sprint Backlog, this paragraph exists (I added the emphasis to make a point).
The Sprint Backlog is a plan by and for the Developers. It is a highly visible, real-time picture of the work that the Developers plan to accomplish during the Sprint in order to achieve the Sprint Goal. Consequently, the Sprint Backlog is updated throughout the Sprint as more is learned. It should have enough detail that they can inspect their progress in the Daily Scrum.
Given your suggestion that they Developers commit to the completion of the initial set of items selected from the Product Backlog, how would they be able to adjust their work as they learn new information. The commitment is to the Sprint Goal as it should not change. However the work needed to accomplish it may, and probably will, change.
This paragraph follows that one I used previously. Again I added the emphasis.
Commitment: Sprint Goal
The Sprint Goal is the single objective for the Sprint. Although the Sprint Goal is a commitment by the Developers, it provides flexibility in terms of the exact work needed to achieve it. The Sprint Goal also creates coherence and focus, encouraging the Scrum Team to work together rather than on separate initiatives.
I hope this helps clarify your thoughts. Never take a single sentence/paragraph in the Scrum Guide by itself. The guide needs to be viewed in it's entirety in order to make sense. At least that is my opinion.
"The Developers have realized that they have over committed themselves for the Sprint. How should they review and adjust the work?"
A supposed "over commitment" is not a reason to do anything in Scrum. The concept does not exist. You either commit to something or you don't. Commitment is not a sliding scale.
If a Sprint Goal is at risk, the team can adjust the forecast of work so it is then met. By collaborating with the Product Owner, for example, the Developers may adjust the Product Backlog items selected.
Where does this question come from? You might wish to challenge the author.
In the section about the Sprint Backlog there is a phrase “If the work turns uit to be different than the expected… “. That should answer your question. Cheers.