Skip to main content
All sections of the BVOP™ Ultimate Guide are part of our management certification training. Get Certified

Sprint Review

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.

Done work

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.

The demonstration

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

Situation

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.

Reaction

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.

Situation

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.

Reaction

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.

Situation

An outside business person asks the Scrum Master of the team if the product increment can be presented to real users this week.

Reaction

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.

Situation

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.

Reaction

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.

Situation

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.

Reaction

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.

Situation

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.

Reaction

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.

What is a Sprint Review meeting (Scrum event)?
Comments of our guests
  1. Nathan Gordon
    Hello mates. The Sprint Review event looks long and arduous. Is it possible to separate all discussions and meetings into smaller events? Is it possible, for example, to have a product review (demo) and then a separate meeting to give feedback? When are we ready to move on to this next meeting to refine our product backlog, etc.
Author

Web site
Your Comment
 

The BVOP Certificates

Certified Chief Executive

The BVOP Chief Executive is the core driver of the Business Value-Oriented Principles and the most advanced figure and leads the interest of the organization.

Get Certificate $1290   $720

Certified Program Director

The BVOP Program Director manages the entire Program Management Office and possess exceptional expertise and applies strategies.

Get Certificate $720   $490

Certified Agile Director

The BVOP Director is the most advanced and important role inside Agile products and services-based organizations.

Get Certificate $440   $220

Certified Project Manager

The BVOP Project Manager is an advanced and competent business, product, and technical role and a key factor for the success of the projects.

Get Certificate $280   $130

Certified Product Manager

With the advancing design, development, technical, and business knowledge, the BVOP Product Manager is a master role and decision-maker for the products.

Get Certificate $280   $130

Certified Product Owner

Responsible and skilled BVOP Product Owners balance both business and technical needs using Agile approaches and provide business value for products.

Get Certificate $180   $90

Certified Scrum Master

The BVOP Scrum Master role combines skills, Agile thinking, and project management practices to enchant processes, teams, and stakeholders.

Get Certificate $140   $70

Certified Human Resources Manager

People are the greatest assets of any organization. Balancing the people and organization needs

Get Certificate $140   $70