Can the sprint backlog be changed?

Hi Harsha,

A slightly earlier line in the Scrum Guide provides relevant context: 

The Sprint Backlog makes visible all of the work that the Development Team identifies as necessary to meet the Sprint Goal.

The purpose of the Sprint Backlog is to work towards the Sprint Goal. If you're not already setting a Sprint Goal, please read up on it (including in the Scrum Guide), as it's a vital concept within Scrum - essentially it's the reason for having a Sprint.

Also from the Scrum Guide:

As the Development Team works, it keeps the Sprint Goal in mind. In order to satisfy the Sprint Goal, it implements the functionality and technology. If the work turns out to be different than the Development Team expected, they collaborate with the Product Owner to negotiate the scope of Sprint Backlog within the Sprint.

This puts the emphasis on the value, and gives the Scrum Team freedom to adapt to new insights, and deliver what is really important (the Sprint Goal), rather than what had been defined previously (backlog items).

In answer to your question, yes items may be pulled from the Product Backlog, but it could also happen that the Development Team removes tasks that are discovered to be no longer relevant, or adds bugs/features that need to be addressed (e.g. to enable use or testing of a feature, so that the new Increment satisfies the definition of "Done").

Ultimately the Development Team change the Sprint Backlog as they need to, in order to meet the Sprint Goal.

As was stated before, you'll find that the Sprint Backlog modifications typically revolve around different timing of certain pieces (1 item was set to be the last week of the sprint but was changed to be the 2nd, for example) or teams removing an item(s) and push the next sprint. In my time as the Scrum Master, it was rare that we pulled something from the Product Backlog in the middle of a Sprint.

 teams removing an item(s) and push the next sprint.

Curtis, I am assuming that the Development Team in your example is not moving items out of the Sprint Backlog without collaborating with the Product Owner on it, and that the item in question is not critical to the delivery of the Sprint Goal?

Personally, I would not associate re-prioritization of Sprint Backlog items as the changes cited by the Scrum Guide that a Development Team may make to the Sprint Backlog.  The Guide explicitly states the following:

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.

As new work is required, the Development Team adds it to the Sprint Backlog... When elements of the plan are deemed unnecessary, they are removed. 

Emergence, adding, removing... these have nothing to do with re-prioritization.

Just to make sure I understand all the great insight here, when this happens (the changes in the sprint backlog - either adding or removing), this will result to 'scope creep' right?

As when I read further regarding scope creep, this seems to be something that we want to avoid doing within a sprint (as sprints normally lasted within a short period - so it seems like its better to perform any changes on adding or removing during the next sprint planning). But from the scrum guide, it doesn't highlight this enough (changes needs to be considered carefully and weigh in the impact towards scope creep)

Do correct me I'm wrong, and thanks in advance!

Just to make sure I understand all the great insight here, when this happens (the changes in the sprint backlog - either adding or removing), this will result to 'scope creep' right?

Shouldn’t the result be an improved ability to meet the Sprint Goal?

My definition of Scope Creep is when work is added to current efforts to introduce new opportunities.  If you do add items to a Sprint Backlog they should be done in order to allow the Development Team to accomplish the current Sprint Goal.  In that case you are not introducing any new functionality.  You are just reacting to new information as it pertains to your current goal. To prevent Scope Creep, only items that support the current Sprint Goal should be added to the current Sprint Backlog.  Anything else should be added to the Product Backlog and considered for inclusion in a future Sprint to support a future Sprint Goal.  The "scope" of a Sprint is to accomplish the Sprint Goal.  Adding items to the Sprint Backlog that supports the satisfaction of that "scope" is not scope creep.  It is just smart. 

Does that help clarify?