Sprint backlog
While reading the "scrum handbook" published by you from Scrum.inc; In the initial paragraph:
"At the beginning of each Sprint, a cross-functional team selects items (customer requirements) from a prioritized list. They commit to complete the items by the end of the Sprint. During the Sprint, the chosen items do not change. Every day the Team gathers briefly to replan its work to optimize the likelihood of meeting commitments."
Here its mentioned that Sprint backlog items will not change during the sprint;
When we read the Scrum guide 2017 for Sprint backlog :
"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."
How to interpret the quoted statements about sprint backlog.
There's no conflict in these statements.
At Sprint Planning, the team crafts a Sprint Goal and selects Product Backlog Items from the Product Backlog. However, the Sprint Backlog is the Product Backlog Items selected for the Sprint plus the plan for delivering them. What this plan looks like may vary by team, but in my experience, it's not uncommon to visualize it as decomposing the selected Product Backlog Items into work tasks that need to be done to complete the Product Backlog Items.
The idea in this "Scrum Handbook" (I'm not familiar with this publication) is that the set of Product Backlog Items is fixed. I'm not sure when it was published, but newer revisions of the Scrum Guide place a greater emphasis on the Sprint Goal as the fixed item in the Sprint rather than the set of work. The idea from the Scrum Guide is that the Development Team is constantly refining the Sprint Backlog as they do work, find new work that is necessary, or complete work. If the Sprint Goal becomes invalid or cannot be achieved, there is a consideration for terminating the Sprint, but this is called "traumatic" in the Scrum Guide.
I believe that the Scrum Handbook is a little out of date, focused more on output rather than value and outcome, but the general idea that the Development Team shouldn't be changing the Product Backlog Items selected for the Sprint during the Sprint on their own without consulting the Product Owner seems correct.
Where did you get this Scrum Handbook from? Is it free? Is it downloadable? I am curious to read it.
The latest version of the Scrum Guide (Nov 2017) is the source of truth.
As far as I know, the Scrum Handbook has not been updated since 2010.
How to interpret the quoted statements about sprint backlog.
The User Stories belonging to the Sprint Backlog do not change when the Sprint is in progress. However, during the Sprint cycle, the items on the Sprint Backlog are updated and moved from one column to another. So, the Sprint Backlog is definitely updated during the Sprint cycle but the existing User Stories should not be removed or newer ones added from the Product Backlog when the Sprint is in progress.
Ian I also checked it this way!
thanks for the answer
The "scrum handbook" you are referencing is from scruminc.com. It isn't the actual Scrum Guide (https://scrumguides.org/scrum-guide.html). It is provided by a for profit organization that from it's website states is a consulting company. The author of the book is the son of Jeff Sutherland so there is a lineage connection to Scrum. But that doesn't mean that the book is correctly stating Scrum principles and practice.
The Scrum Guide only uses the word commitment twice. Once when it states it as a Scrum Value and second when it states
People personally commit to achieving the goals of the Scrum Team.
The Sprint Backlog is used to create a forecast of the work that will be used to satisfy Sprint Goal. That forecast will usually change as more information is discovered while doing work.
I have not read the Scrum Fieldguide (https://www.scruminc.com/the-scrum-fieldbook-master-class/) so I cannot comment on how accurate it portrays Scrum. But I would say that when you find descrepancies the Scrum Guide would be the source I used over anything else.