Hello! Today we’ll continue with the Scrum FAQ series, and our topic will be the Review Meeting. The name itself is quite self-explanatory, but what happens during this meeting? Who should attend? Whose responsibility is it to show the items developed and what happens when something fails? In today’s post we’ll try to clarify all these doubts and suggest ways for you to run this meeting so that everything runs smoothly.
According to the Scrum method, the Review Meeting should take place just after the development period of a Sprint. The purpose of this meeting is to present the Product Owner (PO) with all deliverables that were produced by the Scrum team and she has the participation of the team. During this meeting, the team has the responsibility to show the PO the work that was done, the SM has a responsibility to prevent the meeting from going off topic, and the PO has the responsibility to approve or disapprove the new features shown.
And why is it the team that presents what has been developed? This responsibility is actually one of the most important tasks for the team, and should always be respected. During planning meetings, the team commits to the PO to develop certain items from the product backlog and, at the end of the work cycle, it is the team who must show the results to the PO and take responsibility for what was produced. In addition, the team should also discuss with the PO solutions, and hear suggestions and views on what was presented.
The role of PO in this meeting is to evaluate whether what was produced is consistent with what was expected, and to validate Sprint. For a Sprint to be validated, it is necessary that the functionality delivered by the team meets the goal of the Sprint, which was agreed upon during the Planning Meeting. The fact that some of the Sprint Backlog items may be disapproved by the PO does not necessarily indicate that the Sprint was not successful. If the failed item is not related to the Sprint’s goal, it can still be validated. We just have to keep in mind that if an item is disapproved by the PO, even though part of it may have been approved, the whole task will be returned to the Product Backlog, and no points will be awarded to it. In the next Sprint, depending on the priorities set by the PO, this item can be put back into the Sprint Backlog, with the same estimate as before, and only than completed.
What was said in the post “To release versions during production is like running on asphalt” also applies to this moment in the validation work. Therefore, here at GPE, we follow the following practices: set up a script of the presentation and test the project on a local server. When mounting a roadmap presentation, we try to think of all the steps that should be taken in order to present all of the features produced, allowing the team to review the entire stream and check if something went unnoticed and needs to be reviewed. By performing the test on a local server, the team can simulate the environment that will be used in the presentation and try to identify and correct possible problems of environment configuration. These practices allow the team to have more peace of mind during the meeting and avoids problems where the answer is the now famous “on my computer it was working just fine”.
A final practice should always be used: do not wait for the Review Meeting to contact the PO. The more opinions and impressions collected from the PO during the development process, the greater the chance that the Sprint Backlog item will be approved.
Any other question? Do not forget to send your comments and watch the video lesson about this topic on our YouTube channel, Scrum University!
