Finishing a sprint Sprint review meeting

Finishing a sprint
Sprint review meeting
At the end of each sprint, a sprint review meeting is held. During this meeting, the Scrum team shows what they accomplished during the sprint. Usually this takes the form of a demo of the new features.
At the end of each sprint, the ScrumMaster leads the sprint demonstration review meeting. The team demonstrates to the product owner what it has completed during the sprint. The sprint review meeting is intentionally kept very informal, typically with rules forbidding the use of PowerPoint slides and allowing no more than two hours of preparation time for the meeting. A sprint review meeting should not become a distraction or significant detour for the team; rather, it should be a natural result of the sprint.
Participants in the sprint review typically include the product owner, the Scrum team, the ScrumMaster, management, customers and developers from other projects.
During the sprint review, the project is assessed against the sprint goal determined during the sprint planning meeting. Ideally, the team has completed each product backlog item brought into the sprint, but it's more important that they achieve the overall goal of the sprint.
Sprint Retrospective
After the sprint review, the ScrumMaster leads a sprint retrospective.
The sprint retrospective is intended to answer two important questions:
• What went well during the previous sprint that we should continue doing?
• What could we do differently to improve the product or process?
The sprint retrospective meeting is often led by the ScrumMaster, who documents a list of action items for implementation. Those items may be added to the product backlog if the product owner agrees with them. Usually, the ScrumMaster would update the product backlog based on the latest information and business needs.

Releasing an iteration
An agile project team typically uses several iterations or deliveries of software instead of waiting until the end of the project to provide one product. Based on the updated backlog the team will plan the next iteration.
In this process, the team validates the tasks assigned to the next sprint. The team updates its estimates based on the team's conversation about each task. The team then adds each estimated task to the next sprint until the available velocity is met. Finally, the team estimates additional tasks and adds them to the next iteration. The team performs these steps until the velocity of that iteration is also exhausted.
Once tasks are aligned to sprints, the team can determine a rough timeline of when each workload will be ready for production release.