agile sprintreview
|
The iteration review meeting is held on the final day of the iteration. The length of the review meeting is relative to the length a team has chosen for their iterations, but should be limited to four hours. The goal of the review meeting is to successfully demonstrate the features and functions completed during the iteration. The meeting gives product owners, users, management, and other project stakeholders the opportunity to see the actual progress being made on the project. The benefit of conducting these periodic reviews is immense, to both the team and the overall project community. The visual reinforcement of demonstrating real working software goes a long way in building stakeholder and management confidence. It also helps to the product owner see what they are getting and enables them to provide better feedback if what has been demonstrated has failed to meet their expectations. Not having this meeting removes an important opportunity for the team, the product owner and the stakeholders to collectively experience the value being delivered in the form of working software. A recommendation is to start the review with an accounting of what was originally planned but not completed. This sets appropriate expectations for the meeting. The last thing you want is an executive watching for a favorite feature, only to hear at the end of the meeting that their feature won’t be demonstrated. This may end the meeting on a negative note. Being able to focus on stories that were completed ends on a high note and gives the team an incremental win, something that most developers and testers don’t get to experience in traditional software projects. As noted in the book Agile Coaching by Rachel Davies & Liz Sedley, “…the secret to successful meetings lies in the preparation.” This is especially true for review meetings. A great deal of time should not be spent preparing for a review, as it should just be a natural part of the team’s rhythm. However, some thought should be given to:
|
|
