What is a Sprint Review Meeting | Iteration End Review Meeting
When a sprint or an iteration ends, the time comes to demonstrate the working software as per the stories and requirements committed originally. This is usually done in what is called a Sprint Review Meeting. During the Sprint Review Meeting, the team demonstrates working software corresponding to project backlog items they have completed in a given sprint.
The focus of sprint review is on working software. Powerpoints, speeches, lectures and other diagrams/ presentations are not allowed. In fact overall, the meeting is kept very informal. and typically, like the Sprint Planning Meeting, last only about 01 hour per week of sprint work planned. The teams attention, selection of practices and processes is all done with regards to faster delivery of working software. For instance, since the teams focus is on delivering working software, all the arrangements [arranging room, projector, getting the environment ready etc.] are done by the Scrum Master.
Product owner, The Whole Team and Scrum Master, all attend the Sprint Review Meeting. This is done to ensure that people who have developed the software are there to answer any questions the product owner has and for product owner team [customers, stakeholders, product owners] to see what is coming up from development team. This also improves the communication in the team, with each team member further strengthening the teams understanding of the product and product owner expectations. The team would typically demonstrate each code it has written either through GUI, mock objects or through API calls. The product owner team can give better feedback after seeing something working rather than on abstract IT diagrams. The teams are looking forward for the following feedback in the sprint review meeting:
- Whether they completed enough requirements
- Whether they completed requirements quite early
- Whether they understood the requirements and translated them to working features well enough
This feedback helps the team and product owner to plan better for the next sprint. The team [together] and product owner both take back points for themselves too. For instance, product owner sees if some more requirements need to be added/ edited/ deleted for next sprints and also for the team to see if they need to do better to understand or compelete more requirements.
After the sprint review is over, the date for next sprint review is announced and the team moves to Sprint Retrospective.