Continuous Delivery and the Sprint Review

@Richard, the Scrum Guide addresses this and I have experienced this quite a lot as well.  You are able to deliver any time and continuously throughout a Sprint however when do you get feedback on the combination of what was delivered and inspect the whole, that is the Sprint Review. The Sprint Review is still important as pieces delivered may not be enough to get feedback without the whole and don't on their own meet the Sprint Goal.

Although inspecting the product and getting feedback on the work done over the course of the Sprint is a large part of the Sprint Review, there are other aspects that could be useful. Collaboration to make sure that the Product Goal is still relevant and update it if necessary, understand any changes in customers or users and how the product is being used or could be used, reviewing timelines and budgets, and so on. The Sprint Review is a two-way synchronization between the Scrum Team(s) working on the product and the customers, users, and other key stakeholders of the product.

I would be interested to hear feedback from the forum as to the relevance of the Sprint Review in organisations where CI/CD is used and what conversations/questions the wider Scrum team would have within such a Review? 

The critical output of a Sprint Review is an updated Product Backlog. The work that has been Done is reviewed, along with the work that remains to be Done for whatever reason. It presents the last responsible moment to ensure that the latest business intelligence and market feedback, including that brought by invited stakeholders, is considered and incorporated before the next Sprint begins.

 The Product Owner and developer(s), BA and Tester review the developed item to ensure it meets business expectations;

So the Scrum Team inspects and delivers.  But where is the feedback from stakeholders?  And before you say that you can't get the users/customers present in the Sprint Review, remember that not all stakeholders have to be external.  Support personnel make great stakeholders as they understand the customer and the way the product is used very well.  Sales, Marketing, Advertising could all be stakeholders.  

In my opinion the main part missing is @Ian's point.  If you do not have a Sprint Review, you are not completing the Sprint and revisiting the Product Backlog for the future. 

With all the respect to other commentators(with excellent feedback) I have two remarks

1. Who is "Tester" ? In Scrum all tests should be done by the Scrum team, no external testers

2. Increment can be born at any time during the Sprint, the Sprint review is NOT a gateway for increment.

3. 2020 Scrum guide contains a wonderful phrase which not many ppl noticed

" The moment a Product Backlog item meets the Definition of Done, an Increment is born"

It means that in fact no human intervention or approval is neccessary for increment to start existing. 

Thanks you for all the comments, it is good to occasionally useful to soundboard some simple questions and check-in with the community (and borrow ideas) as often get trapped up inside my own Scrum event-horizon! :)

@Eric - yes I agree, the Sprint Review gives a summary of all done items to the team and stakeholders as to what outcomes have been achieved in during the Sprint and obtain feedback. Thank you.

Thank you @Thomas, good point to use the Sprint Review to align timelines, budgets and the Product Goal. 

@Ian - trying to get stakeholders to attend is always the challenge, but that is for another post.  Market feedback and an updated PB is useful output of the Sprint Review (I'm guessing that Kanban for Scrum could experience similar issues as continuous delivery: as items flow through the Sprint the team must decide how to maximise the value of the Sprint Review).

I like the idea of inviting support personnel to the Sprint Review @Daniel, in my mind it was always senior folks (decision-makers), but the users of the tools would give some alternative feedback.

Thank you @Nicholas - The Tester/QA in my scenario is part of the Development Team and supports developers with in-Sprint testing, you're right, the Sprint Review is not always the gateway to a release.