Iteration Reviews are a crucial practice that can enhance the effectiveness of your development teams. If you are seeking a more effective approach to establishing goals and well-organized processes into your project sprints, it is worth delving into what iteration reviews can offer.
In this article, we’ll tell you more about the iteration review process in Scrum, how to conduct it in the right way, and what benefits it can bring to your work organization.
What is an iteration review?
Iteration Review or Sprint Review is one of the Scrum events conducted at the end of the sprint. The main purpose of the event is to inspect what was done during the last sprint. The iteration meeting is one of the answers to “how does a team demonstrate progress?” question, when it comes to accomplishing the sprint goals.
It’s also a great opportunity to collect feedback from stakeholders. As a result, it's possible to make sure the Scrum Team is on the right path towards achieving their objectives and make necessary adjustments to the product backlog.
"The purpose of the Sprint Review is to inspect the outcome of the Sprint and determine future adaptations."
A vital component of each iteration review and the primary outcome of every sprint should be a product increment, a set of releasable product features or updates expected to impact the value a customer receives from the product positively.
Similarly to the purpose of the iteration review itself, releasing product increments as often as possible helps collect feedback in advance and regularly. As a result, we can make sure the product development moves in the right direction and the value generated is increased.
Interested in more tips for Scrum meetings? Check out our FREE sprint planning checklist.
Iteration review vs. retrospective
The Sprint Review happens at the end of each Sprint, but it is not the last event in the Sprint. It's always followed by a Sprint retrospective event that allows reflecting on what went well and what could have been improved in future sprints.
The main difference between the two is the focus. While the Sprint Review's purpose is to demonstrate Increments, overview the progress, and get approval from the stakeholders, the Sprint Retrospective is conducted to monitor and improve the processes that take place throughout the sprint.
Attendees
The iteration review meeting should be attended by: the Product Owner, Scrum Master, Developers, and Stakeholders. As the Scrum Team expects to receive feedback, the presence of Stakeholders is significant.
It is an opportunity to review the progress of the work and identify any areas for improvement or adjustments that may be necessary to achieve the project's goals. If the key stakeholders cannot attend, the Product Owner should follow them up to report progress and get feedback as quickly as possible.
The owner of the meeting is usually the product owner, but it doesn't mean they should conduct the meeting alone. It is even recommended to give the floor to developers to present their own work.
"The Scrum Team presents the results of their work to key stakeholders and discusses the progress toward the product goal."
It's crucial to have iteration review meetings regularly in order to adjust subsequent sprints based on stakeholder feedback and keep the product developed in a way that meets customers' needs.
During this meeting, the Product Owner, together with Scrum Master, should encourage stakeholders to provide feedback and make sure they have time for interaction. It would be great if stakeholders could try the product on their own.
Looking for more tips and tricks from project management experts? Take a look at: "Project manager's guide to time tracking"
Duration
The Sprint Review time box is restricted to a maximum of four hours for a one-month Sprint. The Scrum Guide suggests that the event is usually shorter for shorter Sprints.
For example, in Apptension, we schedule one-hour meetings once a week or 2 hours meeting bi-weekly. It really depends on the project's complexity and how quickly the client requirements are being updated. If we are faced with many unknowns and the pace is fast, we recommend having shorter meetings every week. With this approach, we can clarify the requirements well enough to put them into the next sprint.
Prerequisites to iteration review
In a sense, preparation actually begins during Sprint Planning, where the Scrum team commits to delivering a defined scope of work during the Sprint. The scope of work is divided into smaller units called user stories – instructions that are usually written in informal natural language to describe how a piece of work will deliver a particular value back to the customer.
Before the iteration review event, the Product Owner should confirm which user stories are completed and meet the definition of "Done." Also, the Product Owner should decide which user stories are ready to be presented – only finished ones should be included in the presentation. In their turn, unfinished stories should go back to the product backlog.
"User story is a brief, simple statement from the perspective of a user or customer that describes what they need to achieve a goal or objective, and why they need to achieve it."
The team should decide who will conduct the meeting. It can be a Product Owner who is a connection between the team and stakeholders. But it is even better if the Product Owner prepares a short introduction, and then one of the developers can present the work done.
Before the presentation, you should also prepare the test scenarios aligned with the acceptance criteria of the presented stories. This should simplify the stakeholders' process of deciding if the story is accepted or needs some improvements.
Iteration review agenda
"The Sprint Review is a working session, and the Scrum Team should avoid limiting it to a presentation."
It is recommended to minimize the use of slides. The purpose of the iteration review is to get feedback on working software functionality, hardware components, etc.
- In the beginning, it's worth reminding the team about sprint goals.
- The next step is walking through the user stories which were planned to deliver (each finished story should be already on stage, tested beforehand, and ready to be presented to stakeholders). It also keeps all parties on the same page.
- The team (preferably developers) presents the progress achieved during the sprint.
- The most important part – gathering feedback from stakeholders.
- Unfinished user stories should also be mentioned as an opportunity to discuss risks, impediments, or underestimations. All fallbacks should be noted down and become a point of discussion during sprint retrospective meetings to improve the performance of the next sprints.
"During the event, the Scrum Team and stakeholders review what was accomplished in the Sprint and what has changed in their environment."
Stakeholders must be present at the review meeting and provide constructive feedback. When they miss meetings, they lose track of progress in development which may influence the product outcome. When working in a fast-changing environment without receiving feedback regularly, it can cause difficulties in aligning products to customers' needs.
If all the acceptance criteria are met, the Product Owner should confirm that work is done. If stakeholders decide that something needs to be changed and didn't meet acceptance criteria, it should be written down in the Backlog. The team would bring it up in the planning meeting for the subsequent iterations.
Also, during that meeting, the team and stakeholders try to understand if something has changed in the environment, and if needed, the product backlog may be updated accordingly to improve the solution under development.
Next steps after the iteration review meeting
After the Sprint Review meeting, the Product Owner should make a summary to ensure everything is understandable and everyone knows what should be considered during the next sprint planning. As mentioned above, the Product Owner should check and update the statuses of all presented stories.
If the story meets acceptance criteria and the definition of done, it is considered done, and there is no need to return to it again in the further development stages. Otherwise, new tickets should be created, and if something is still unclear, the team should clarify it with the stakeholders before the next sprint planning.
The conclusion
Iteration reviews are an essential practice for any Agile team looking to improve their development process and produce high-quality results. By fostering collaboration, communication, and continuous improvement, iteration reviews can help teams stay focused, make timely adjustments, and deliver successful projects.
If you’re looking for a development team that implements not only iteration review, but other efficiency practices from Scrum, hit Apptension up for an estimation, and we’ll deliver your application, website, or else in a timely manner, maintaining high quality.