At the end of the sprint cycle, a review meeting is required to have the team present the completed functionality to the product owner and stakeholders. Most of the practice of sprint audits is for team members to demonstrate functionality, to answer stakeholder questions about presentations, and to document desired changes. A review meeting can draw the attention of stakeholders, let others know what the team is doing, and get important feedback. Doing a demo will also force the development team to actually do some work. The team prepares workstations and equipment, and so on, to showcase the new features of the product team prepare for Sprint audit practice should not exceed 1 hours
The meeting Process (4 hours) ensures that all people are clear about the goal, and if someone doesn't know about the product, take a few minutes to describe it. The team describes the results of the Sprint one by one, as well as the new features, as per the issues in the Backlog. If the product owner wants to change the functionality: Add a new question to the product backlog if there is a new idea for the feature: Add a new question to the product backlog if the team reports that the project has been hampered, it has not been solved yet: by adding the barrier to the end of the barrier Backlog, ScrumMaster announces the location and time of the next audit to the product owner and all stakeholders.
The outcome of the meeting was a consensus on the outcome of the Sprint and the state of the product's development.
Others Let the presentation focus on the business level and don't focus on technical details. Focus on "What we Do", not "what we do" some sprints may contain many bug fixes, and don't show too many bugs fixed in the review meeting, unless it's important.