On scrumguides.org, the following is said about the result of a Sprint Review:
The result of the Sprint Review is a revised Product Backlog that defines the probable Product Backlog items for the next Sprint.
However, a Sprint Review is something you do at the end of a Sprint, meaning the next one is about to start and the top items of the Product Backlog should already be ready for that.
How does the revision of a Product Backlog during Sprint Review influence the next Sprint’s Backlog? Are changes during Review typically used in last-minute changes to the next Sprint’s Backlog? Do the Product Owner and Development Team both have a say in how the next Sprint is adjusted? Or should revisions to the Product Backlog typically not influence the next Sprint (but tops the one after that)?
I’ve tried answering my own question by carefully reading through aforementioned guide, and have checked similar questions and suggested duplicates on programmers.se, but haven’t quite found an authorative answer.
By-products of the sprint review include a possible change to average velocity, and feedback from the stakeholder. That feedback might end up being “no, that’s not what I wanted” or “excellent! Let’s use that design for the rest of the app!”. All of that can potentially change the items or order of items on the backlog.
Are changes during Review typically used in last-minute changes to the next Sprint’s Backlog?
I wouldn’t say typically, but it can happen. The reason for the review is to make sure you’re meeting the needs of the stakeholders. The whole point of agile is to be able to adapt to changing requirements, and the review is perhaps the first place where a need for change becomes apparent.
2
I’ve come across this and similar problems in scrum, basically I think this comes down to whether you have a period of time where no ‘work’ (in terms of tasks on the board) is being done between sprints
Some teams will move right into the next sprint with only a couple of short meetings
Some teams will have a break of a couple of days between sprints where they do the various meetings, sort the back log, estimate etc
Some teams will have whole weeks, or maybe release/bug fix sprints between ‘normal’ sprints
Personally I feel the ‘no break’ option is the best. It de-emphasizes meetings and artifacts in favor of task progress and encourages all tasks to be put into the backlog rather than having special, non sprint tasks
Hopefully your Scum master has sorted the backlog during the previous sprint and it can be quickly reordered without running out of well defined/well estimated tasks.