What is a Sprint Review meeting? A Sprint Review meeting is a Scrum event held at the end of the Sprint to inspect the Increment and adapt the Product Backlog if needed.
Sprint Review is a Scrum event that takes place at the end of a Sprint. The Scrum Master role supports this event, ensures that the meeting takes place and that all participants understand the purpose of the event.
The purpose of the Sprint Review event
Sprint Review is conducted to demonstrate what was completed during the Sprint, to seek and receive feedback, and to encourage cooperation between all parties in the project.
Event attendees inspect the increment and, if necessary, adapt the Product Backlog.
The goals of the Sprint Review event are:
- A review of what exactly was achieved during the Sprint.
- Product increment inspection.
- Adaptation of the Product Backlog.
- Get helpful feedback for the next Sprint.
Duration of the Sprint Review event
For a one-month sprint, the time for this event is a total of 4 hours. For two weeks - respectively, the event is 2 hours maximum. For a one-week sprint, time is limited to 1 hour.
The Scrum Master role keeps track of time and focuses on essential topics of the meeting.
Participants in the Sprint Review event
The whole Scrum team and various stakeholders.
A Product Owner role that invites key figures to the meeting at its discretion.
End-users may also participate in the event.
Remember Definitions of Done. Each item in the Sprint Backlog has a clear definition for completion. Officially the Product Owner role during this event accepts or rejects the work done, citing the Definitions of Done.
If work is beautifully created, but a small part of Definitions of Done is not fulfilled, the Product Owner role may declare the item unfinished. It is good practice not to accept such items, as a small detail or incomplete procedure can create a problem.
However, the Product Owner role may accept items that do not cover all Definitions of Done completely. This will be the business decision of the Product Owner role.
In theory, the Product Owner role should not do this.
The Product Owner role returns unfinished items back to the Product Backlog at its discretion. It is the most common and logical that the returned items are planned for the next Sprint.
A demo is a fairly common, simplistic name for this event. However, keep in mind that product demonstration is only one part of the entire Sprint Review event. The term Demo often gives the wrong idea about a Sprint Review event.
Some teams do not make a demonstration at all and transfer this part of the event to the Product Owner role, or directly notify the customer and stakeholders when there is a ready-to-view part of the product.
However, the typical review has its benefits for the Scrum principles of transparency, inspection, and adaptation. During the review and comments from customers or customer representatives, if the Scrum team is present, there is an opportunity to observe the spontaneous reactions and impressions of attendees.
The comments and feedback are direct, instant, and first-hand. This information may be more valuable than presenting analytically ordered information after the review, as the Development Team can capture the nuances.
Sometimes the client may not express his or her opinion clearly or precisely what he or she thinks about a particular issue. Still, the reactions, body language, exclamations, and comments reveal valuable information.
However, participants who monitor and inspect the increment must provide some formal and understandable feedback to the Scrum team. This often happens during a Sprint Review event, but the Product Owner role can receive a lot of additional information, comments, notes, or questions after the event is closed.
After reviewing the increment, the discussion of Product Backlog items that are placed at the top of the Product Backlog begins. After the demonstration, stakeholders can come up with ideas for necessary refinements that need to happen right after the demonstration (during the next Sprint).
Some Product Backlog items may be commented on as being referred to as lower priority or may be dropped altogether.
Not only business persons or customer representatives participate in the discussions. The Development Team observes, listens carefully, and can also offer their opinion.
Businesses or clients can ask the Development team questions about the increment. The Development Team strives to respond clearly and simply, in detail, or briefly, according to the situation.
The result of the Sprint Review event
The result of a Sprint Review event should be:
- Presented increment
- Received feedback
- Constructive discussion
- Prioritized Product Backlog
- Release Plan (When exactly or how exactly the increment will see the light of day in front of other business representatives or directly to end-users).
The Sprint Review event may also include additional topics. Topics of conversation may be indicative estimates of time, budget and cost, market dynamics, consumers, potential new opportunities, and the business value of the product.
Although these are important and interesting business topics, these parameters should be more closely related to nearby upcoming sprints (best next Sprint). It is advisable to avoid plans and projections for the distant future.
The demonstration, feedback, completion, discussions, item rearrangement - all these situations can be defined as "sub-events" in the whole regulated Sprint Review event.
Starting and ending a Sprint Review event may not always be the same. The Product Owner role invites business stakeholders and various representatives or users. There may be many participants and factors involved. Sometimes the client does not come to the meeting or send different people at different times each time.
Not only the sequence of the event but the format of the event, as well as specific details, will depend on the client (or their representatives) or business stakeholders of your organization.
The Sprint Review event, with a one-week sprint, has a limit of 1 hour. For all discussions, inspections, reviews, item arrangements, comments from various business people, the time allocated for the event may not be sufficient. Respecting the time limit of the event is a real and serious challenge.
In the real world, Scrum rules are often broken. Businesses may not know them or may not be interested in the Scrum recommendations.
The Scrum Master role should interfere with such situations and explain that wasting time hinders work and complicates planning.
Sensitive situations and reactions related to the Sprint Review event
Get together in the usual place for your Sprint Review event. It turns out that the attendees are the Scrum Master role, the Development team without a new beginner, the Client-side Project Manager, the Client-side Product Manager, Business Analyst, and an external Usability consultant.
The Product Owner role of your Scrum team needs to be called, as it is a key and important role whose presence should not be easily missed. The new member of the Development Team is also advised to be present to familiarize themselves with the atmosphere and processes of the team and organization.
A project manager from your organization came to the Sprint Review event. He listens carefully and watches everything. He is pleased that the work is going well. Finally, he turns to the Scrum Master role and asks when the product increment is expected to be released in a live environment.
Project management topics related to defining milestones are not the theme of this event. It is recommended that the Product Owner role discuss these issues with this project manager after the event is over.
An outside business person asks the Scrum Master of the team if the product increment can be presented to real users this week.
Let's first recall what a product increment is.
During the Iteration (Sprint, the period during which the Development Team works), the Development Team works collaboratively to create a Potentially Shippable Product Increment.
The "Potentially Shippable Product Increment" is a working version of the product being worked on that can be made available to end-users. These "product increments" for this period must be fully completed. There should be no hidden work that still needs to be done.
The inspection is carried out on the "incremented" product, and any adjustments made are made to create a better and more valuable product.
The Potentially Shippable Product Increment is the version of the product that we inspect and review during the Demo but is often not the real product. It's just "potentially ready".
Without real experience in product development, testing, and release processes, one might be left with the impression that the increment is actually a real product. It is a common practice to work on a test version that is accessible only to teams, customers, or business entities, and not to the outside world.
At some point, the incremented product is delivered in a real environment. The Product Owner role is responsible for the release.
When the Scrum team works for a client, they usually first ask the client about releasing the product in a real public environment.
When working on your product for your organization, the Product Owner role can make these decisions on its own if it has all the powers and can formally make such decisions.
The Scrum Master role should not be relevant to either the increment or the real product.
A brief description of this reaction would be that the Scrum Master role should not be relevant to this question and offer answers but instead transfers this topic to the Product Owner role.
The Product Owner role must have the competencies and skills to provide adequate answers and to participate in discussions related to the future planning, budgets, and direction of the product as a whole.
All of these discussions should take place after the end of the Sprint Review event.
The Sprint Review event begins. Shortly after the beginning, the client's product manager opens a topic about the project budget. The product manager is not sure if the resources of his organization will be sufficient to continue working on the product for another six months. He also asks your Product Owner for comment and advice on the Roadmap of the product.
The topic of conversation discussed should not be opened during the Sprint Review event, as the topic is not part of the purpose of the event. The Scrum team, and especially the Development team, would engage in conversations that are not within their competence and importance.
Such a dialogue would only distract the participants. However, this is an important topic, and the Product Owner role should be involved and ask the client's business person to remain patient and wait for the event to end.
The Product Owner role of the Scrum team can enter into discussions with the client's business person if he/she has the competence to do so. BVOP recommends that Product Owner roles, as product-oriented, be adequate in budget talks and project futures, and actively participate in Roadmap planning.
Your client's product manager does not approve Definitions of Done for one of your User Story and refuses to accept the finished development. Everyone is staring at the Scrum Master and Product Owner roles of your Scrum team.
The initial spontaneous reaction of most Product Owner or Scrum Master roles would be to satisfy the claims of a business person who has remarks about in-house team artifacts.
Once this product manager has access to the Scrum team work materials, then we can talk about a situation where the organization has given its client access to internal materials and resources.
BVOP recommends avoiding such data sharing as this can lead to over-active involvement by outsiders in the team's work. Delays and waste are also typical results.
It is up to the Scrum team to decide whether they prefer outsiders to have access to the team's resources. The reason for such shared access would probably be a desire for collaboration and teamwork.
If a productive atmosphere of collaboration between organizations is established, only then we can consider the described case as valuable and important.
If there is a mutual synergy between the teams of the organizations or regulated official activities for material inspection that is indirectly related to the product increment, then the Product Owner role should pay attention to the comments made.
Definitions of Done can be adapted and modified as needed.
Shortly before the end of the Sprint Review event, a team member says out loud that a User Story covers all Definitions of Done. Still, the finished work is not visually the same as the attached sketches in the specific Product Backlog item discussed.
The materials provided in the Product Backlog Items serve as a reference and guidance for the Development Team. Often, there is nothing wrong with a sketch and a real result that have significant differences. The Development Team decides for themselves how to get the job done and what the product increment can provide at the end of the Sprint.
If all the terms in Definitions of Done are covered, and all tests have passed successfully, often these positive results show excellent work. If stakeholders also have no claims about the product increment, this is the final indicator of successful work.
After a team member has made such a comment, it would be appropriate for all Scrum team members to discuss their way of working and processes so that everyone is aware of the work, processes, and expectations of stakeholders.