sprint backlog & sprint scope

so can the sprint backlog change during the sprint?

Scrum is Agile and one of Agile principles is

Welcome changing requirements, even late in development. Agile processes harness change for the customer's competitive advantage.

Why should Scrum go against the Agile principle? 

Of course, changing Sprint Backlog has its price and this price needs to be accounted for and weighed against the value we get by the change. And there is not a universal recipe. You always need to know what is the expected value for the customer, what is possible for your team, and of course what is important for your own company. Art of possible and common sense supported by evidence, nothing more. 

I don't fully follow your logic as to why the Sprint Backlog doesn't change in the Sprint. If the Sprint Backlog contains the Sprint Goal, the Product Backlog items selected for the Sprint, and the team's plan for how to deliver an Increment that achieves the Sprint Goal, how does a change to one of these items not reflect a change to the Sprint Backlog?

The word "scope" is only used twice in the Scrum Guide: once to state that, during the Sprint, the Developers can clarify and renegotiate the scope with the Product Owner and again to state that the Developers collaborate with the Product Owner to adjust the scope of the Sprint Backlog without affecting the Sprint Goal. I'd suggest that if the Sprint's scope is adjusted without affecting the Sprint Goal, then they are not the same thing. The Sprint Scope is more closely related to the Product Backlog Items selected for the Sprint and the plan for delivering an Increment. In some way, the team can adjust the Sprint's scope by making changes to the selected Product Backlog Items and their plan.

some questions came to my mind about sprint backlog

My advice is to consider the difference between the team making a forecast and a commitment. Both can be identified in the Sprint Backlog...and while one might be expected to change, the other would not.

yes, I have re-read my first question and it is illogical, if one of three elements of Sprint backlog change, then the sprint backlog itself will be changed

sprint goal can't be changed, while both product backlog items and plan to reach them can be changed. They are ncreased or decreased in number as PO and developers add more details and clarification, in the plan (not during the sprint planning meeting) I will have the whole set of estimates, dependencies, more details to track the product backlog items.

in practise, I image the sprint scope as the tasks put on to the scrum board which are progressed during the sprint, so if I am adjusting these tasks, I am also adjusting the sprint scope, hence, likely the selected Product Backlog Items and their plan, could my idea of scope be reasonable Thomas?

Thank you

Flavia

It's generally better to think of "scope" as the selected Product Backlog items, and tasks as the plan of work. Both may be inspected and adapted during a Sprint if doing so allows the Sprint Goal to be better met.

I don't fully buy into the idea that the Sprint Goal cannot be changed. The Scrum Guide allows for cancellation of a Sprint if the Sprint Goal becomes obsolete. There are also considerations to allow the scope to be "clarified and renegotiated" as more information is learned. Although drastic changes to the Sprint Goal could result in cancellation of a Sprint, I'd suspect that more minor adjustments would be handled through renegotiation. After all, one of the principles of Agile Software Development is that teams "welcome changing requirements, even late in development". A rigid, inflexible Sprint Goal doesn't seem to be consistent with the values and principles of Agile Software Development.

It seems like considering the Sprint's scope to be the work put on a board is reasonable. Scrum doesn't mandate any particular representation for the plan of the Sprint, so it will depend on the team's preferences and tooling. It may not be the only definition of the Sprint's scope, though.

Hi thomas, I agree the sprint goal can change with adjustments, but I don't think they will bring to change the nature / purpose of Sprint. for me, these adjustments mean only a more detailed Sprint goal. and of course if it comes to be obsolete, it is worthwhile cancelling the sprint instead of wasting time.

for instance, if the scrum team come up that the Sprint goal is "add new payment methods" and then developers understand payments method can be through credit/debit card, paypal and Google pay, but the Product owner excludes Googlepay because it isn't used by that specific market they work in, could I say these adjustments are done by developers in agreement with PO?

then, developers breakdown the scope of the sprint hence clarify the product backlog items and refined the plan during the sprint.

@ian good input could you please clarify what you mean a little more?

in this context, I have understood; during the sprint planning meeting the developers FORECAST what items pick to fullfill the sprint goal, during the sprint they get surer and surer of how and what work to be done accoring to the Sprint but they remain COMMITTED to create a usable increment as they are due to their accountabily.

is that what you meant?

Thanks

Flavia

A rigid, inflexible Sprint Goal doesn't seem to be consistent with the values and principles of Agile Software Development.

That's a tricky question. What does the goal mean? IMHO, unlike the sprint backlog, it is not the work to be done. It should be the value to be delivered/the benefit that the users can realize by using our software. 

"Minor changes" caused by new information or better understanding rarely change the value expected by the users. It would rather fit into the definition of "scope changes".

If the value or benefit is abruptly changed it typically means that we discovered something that changes our whole understanding of the user. Another good example would be the user's priorities changed due to some external factors (e.g. unexpected future regulation rule is published with tight deadlines set). IMHO the reason for canceling the sprint, in this case, is a reflection of the idea that in these cases the changes cannot be handled withing changing the scope. 

Of course, it is true as long as the sprint goal is expressed in the value metrics. Something like "Decrease time of operation by 20% to allow the teller to handle more clients" or "Increase profit by $250/client by reducing fees paid to XXX service". 

If the goal is "deliver feature XXX to the customer" (and I saw it a lot... :-(( ) then the goal is just a short way to express the scope and the same rules as to the scope should apply. Or better the team would be coached to set goals. :-)

Hi thomas, I agree the sprint goal can change with adjustments, but I don't think they will bring to change the nature / purpose of Sprint. for me, these adjustments mean only a more detailed Sprint goal. and of course if it comes to be obsolete, it is worthwhile cancelling the sprint instead of wasting time.

for instance, if the scrum team come up that the Sprint goal is "add new payment methods" and then developers understand payments method can be through credit/debit card, paypal and Google pay, but the Product owner excludes Googlepay because it isn't used by that specific market they work in, could I say these adjustments are done by developers in agreement with PO?

then, developers breakdown the scope of the sprint hence clarify the product backlog items and refined the plan during the sprint.

This all seems correct to me. Depending on the context, "add new payment methods" would be a good goal and the team may have a laundry list of potential new payment methods to add. As the Sprint goes on, they may learn things that force them into decisions about adding one payment method versus not adding another and they may not need to even go to the Product Owner to negotiate scope since the goal gives them direction.

in this context, I have understood; during the sprint planning meeting the developers FORECAST what items pick to fullfill the sprint goal, during the sprint they get surer and surer of how and what work to be done accoring to the Sprint but they remain COMMITTED to create a usable increment as they are due to their accountabily.

This seems right. It's more OK for the team to miss their goal than to create a usable increment.