Sprint Backlog
Prod BL is dynamic. How-ever pl. clarify if : "Is Sprint BL is frozen when sprint planning is done ?"
No it's not. What's fixed is the Sprint Goal, not the plan for getting there (i.e. Sprint Backlog). In fact, if you don't adapt the Sprint Backlog as new work emerges, you're not doing Scrum.
To follow up on that, doesn't the Sprint Goal emerge from the features (essentially, user stories) we are planning to deliver?
Generally, we go into the Sprint Planning looking at the top of the backlog and deciding how much work can be completed within the next sprint. It means that the backlog will include a set of stories which will identify the sprint goal.
I understand that the tasks the team is working on can change depending on what they discover during the sprint, however, still not sure about the user stories we selected.
I guess what I'm looking for is a specific scenario example since this topic was a bit confusing to me lately.
Daria,
If I understand correctly, a number of product backlog items may be forecast by the Development Team as both achievable within the sprint time box, and in support of a Sprint Goal that provides focus and motivation for the team around the business value being delivered.
This forecast however, is based on what the team knows at the time Sprint Planning is being conducted. As the Sprint is executed, the team will likely learn more about the items forecast, and may identify a better method of completing the Sprint Goal (simpler, cheaper, more efficient, etc.). The team may then opt to change the Sprint Backlog in order to support this new strategy for meeting the Sprint Goal.
Such changes may involve either adding or removing items from the sprint.
I understand that the tasks the team is working on can change depending on what they discover during the sprint, however, still not sure about the user stories we selected.
Any part of the Sprint Backlog can be revised by the Development Team, irrespective of whether they be stories or tasks or something else. It’s their plan and they wholly own it.
When a Sprint Backlog is revised to better meet a Sprint Goal, any impacted user stories ought to be re-estimated on the Product Backlog to capture however much work is thought to remain.
The Product Owner may or may not decide to retire those stories. Even if they were not needed for the current Sprint Goal, that doesn’t mean they will be unnecessary in future sprints.