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.
May 1, 2009 at 1:16 am
The sprint review is the opportunity for the team to show off what it has achieved during the sprint. While the stories attempted and not completed must get mentioned, it is important not to dwell on this. If people focus on what is not done, the sprint review is hijacked and goes off down a problem solving tangent. Often, when sprint duration is around two weeks, the product owner or customer is not too bothered if a story is not complete because it is expected to be worked on in the next sprint. That is, unless there is some fundamental problem blocking it. The team should be identifying this and determining solutions in the Sprint Retrospective which is a meeting more suited to trashing out issues within the team.
May 28, 2009 at 9:27 am
Hi Peter:
You make a valid point. I think like the sprint, even review and planning meetings should be strictly time boxed. This focuses everyone on the main agenda and how to complete it the best.
Thanks
Vikrama Dhiman
WiZiQ.com