If there are multiple teams working off of one Product Backlog, how best to reflect and close the iteration? I see these choices:

choice 1:
one review per team
one retrospective per team
one consolidated review for everyone at end

choice 2:
one consolidated review
one retrospective per team

choice 3:
one consolidated review
one consolidated retrospective

I have a bias to the last choice, if space is not a factor. What is yours? Do you prefer another way to coordinate these meetings?

Here are my definitions for these Scrum ceremonies.

Sprint Review: Story time.

Only stories which are DONE and accepted by the product owner as matching the criteria are reviewed. Any and all questions are answered until the time-box of the meeting lapses. Priority is on reviewing all the DONE stories and celebrating success. Questions are parked and answered last.

This is a look at what value was created(the software+artifacts) within the last iteration for the Customer and with them present. Outcome should have immediate influence on the product backlog from the Customer. Typically, items are added and some removed. Usually there is at least a little re-sort of priorities.

I am lumping stakeholders, users, product owners, and other business people together as Customers.

Preparation for a review should be no more than 4 hours.
———————–

Sprint Retrospective: Not a bitch fest, and nothing died.

Longer release-level retrospectives are not a post-mortem. Good retrospectives last awhile and are very interactive. Great retrospectives have the 5 stages as listed in the Derby and Larsen book, Agile Retrospectives, as listed on Diana Larsen’s blog. It’s also in my slide deck.

A look at how that value was created (the process+practices) and ways to apply learning. Outcome should have immediate influence on working agreements and best practices.

With smaller groups, the line blurs between the end of the review and the beginning of the retrospective, except that all the chickens are kicked out, with the exception of the Scrum Masters and Agile Coach.
———————–

I start to think of all these types of meetings as review, and have recently heard the term reflection as a way to link them. Types could be: software, artifacts, process, operations, best practices, releases, roadmap, vision, and on and on. All on a syncopated cadence.

Do you agree with these definitions? How do you like to go about them?

I also would like to mention that these ceremonies I think are necessary no matter the process, and ensure their presence in any Kanban system a team I am coaching may be using.