Confuse about a point related to Sprint.

In this context, "scope" means the requirements that have been planned for actioning in the current Sprint.

These requirements are never frozen, but are revised and replanned as needed in order to meet the Sprint Goal.

If you have read somewhere that the scope of the current Sprint is not allowed to change, then the material containing that information is incorrect.

Thank Lan for your help explain to me

Now i am clear about this.

The doc: "Scrum Training Manual" of mgmtplaza.com said that "The Sprint Backlog is frozen after the Sprint Planning".
Now i kow that it is wrong.

Again, thank you alot.

Hello there,

I have another question related Sprint, it is about Sprint planing meeting.

In Scrum-Guide, i found 2 activity occur in same time: "End of this meeting"

1."Work planned for the first days of the Sprint by the Development Team is decomposed by the end of this meeting, often to units of one day or less."

2. "By the end of the Sprint Planning, the Development Team should be able to explain to the Product Owner and Scrum Master how it intends to work.... "

Could you help to clearify my confuse ?

Thanks

Hi,
the planning has 2 main purposes:
A) select PBIs for next sprint
B) create a plan for how to get them done
The two points mentioned by you both refer to the second purpose. 1. is a suggested way to create the plan, and 2. is a way to validate this plan exists.

I am cleared.

Thank you

just be careful of where you study if you're prepping for the PSM exams ... often some scrum sources will describe the items taken from product backlog and then planned into the sprint planning, where the team commits to how much work they can complete and add it to the sprint backlog, THE SPRINT BACKLOG IS FROZEN AND DOES NOT CHANGE DURING THE SPRINT IS WRONG !!
The Sprint Goal doesn't change , if the team realises it has too much work , work that could have been discovered during the sprint from a backlog item, they should raise the issue with product owner, and discuss the issue - then negotiate "the scope" of the sprint ... remember what the scrum guide says , each Sprint can be considered a mini project. Any project scope , by either parties should be negotiable ... unless it makes the project (or sprint in this case) pointless to do or finish.

What could be example of work planned for the first days of the Sprint to be decomposed? Why not the work planned for the whole Sprint?

Apologies. I am confused on this part.

The planning of work for a whole Sprint can be useful, because it makes a forecast for achieving a Sprint Goal transparent. However, does this advantage always justify putting development and delivery in delay?

What if teams first plan just enough to get started on the Sprint Goal, and then replan on a just-in-time basis?

What could be example of work planned for the first days of the Sprint to be decomposed? Why not the work planned for the whole Sprint?

Work planned for the first days of the Sprint by the Development Team is decomposed by the end of this meeting, often to units of one day or less. SG

Would you say it's wise/effective to plan (especially considering the unknowns) for the whole Sprint? If your sprint is one week long, I can (to a certain degree) agree with the argument, but even then I have doubts. Why not start with a few steps, keep the sprint goal in mind, inspect and adapt daily (DS) towards success (a done increment)?

Say you want to spend about a week exploring a mountain range (camp & all) you've never checked. Lots of knows and a few (or, perhaps, many) unknowns. Would it make sense to plan every single day of your journey, or would you plan for the first day (or half a day), then decide when time comes? And decide again and again.