3

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.

Improve this question
2

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.

Improve this answer
2
  • Thanks for your answer. It mostly makes sense. One question though, about "The reason for the review is to make the process better": isn't that what the Srpint Retrospective is for, as opposed to the Sprint Review (at least, as far as scrumguides.org is concerned)?.
    – Jeroen
    May 13 '15 at 11:37
  • @Jeroen: yes, the retrospective is for making the process better. I should have been more clear. In my orignaization the review and the retrospective run together so I tend to forget they are different things. I'll revise my answer a bit.
    – Bryan Oakley
    May 13 '15 at 11:53
0

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.

Improve this answer

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.