We do these to keep stakeholders up to speed with the progress of product development and allow them to feedback and discuss with the product owner and development team any possible amendments to the product backlog which would help to maximise value.
Stakeholders for each review may change based on what our focus has been.
Sprint reviews should be held at the end of the sprint.
While the review is to show off the work that the team has completed in the past sprint, it's important to also explain the reasoning behind why this work was chosen, and what the resulting value is.
For each feature demoed, you should aim to also describe:
The WHO:
- Who was this feature built for? Calling out our users is important.
- Who raised the issue? Does this give context to the issue? E.g "it was raised by a customer following an upgrade". If an internal staff member raised the issue, where they invited to the demo?
The WHAT:
- What was your approach in developing the solution
- Noteworthy implementation details
- Where there personal learnings or challenges along the way?
The WHY:
- What resulting value has been created?
Anyone can be invited to sprint reviews, especially if they fall into the WHO category noted in the demo content.
Think about who might be a part of the default invitation, perhaps people from your UX, Architecture, Sales, and Marketing teams?