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.

1. The purpose of the Sprint Review event
   1. The goals of the Sprint Review event are:
2. Duration of the Sprint Review event (meeting)
3. Participants in the Sprint Review event (meeting)
4. Done work
5. The demonstration
6. The result of the Sprint Review event
7. Sensitive situations and reactions related to the Sprint Review event
   1. Situation
   2. Reaction
   3. Situation
   4. Reaction
   5. Situation
   6. Reaction
   7. Situation
   8. Reaction
   9. Situation
   10. Reaction
   11. Situation
   12. Reaction

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 at the right time and that all participants understand its purpose.

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.
• Obtaining helpful feedback for the next Sprint.

Duration of the Sprint Review event (meeting)

For a one-month Sprint, the total time for this event is 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 (for the meeting) topics.

Participants in the Sprint Review event (meeting)

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 well 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 uncompleted items, as a small detail or unexecuted procedure can create a problem. However, the Product Owner role may accept items that do not cover all Definitions of Done completely. 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 practice for those items to be planned for the next Sprint.

The demonstration

A demo is a fairly common 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. They can also directly notify the customer and stakeholders when there is a ready-to-view part of the product.

The typical review has its benefits for the Scrum principles of transparency, inspection, and adaptation. During the review’s comments from customers or customer representatives, 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 data 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 finished.

The next step is the discussion of top priority Product Backlog items. 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 referred to as lower priority or may be dropped altogether.

Not only business-oriented people 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 according to the situation’s needs.

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. Those 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 (at best the next Sprint). It is advisable to avoid plans and projections for the distant future.

The demonstration, feedback, discussions, item rearrangement 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 sends different people each time.

The sequence, format, specific details of the event 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 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 interrupting the process hinders work and complicates planning.

Sensitive situations and reactions related to the Sprint Review event

Situation

Everyone starts gathering for the Sprint Review event at the usual place. It turns out that the attendees are the Scrum Master role, the Development team without the beginner participant, the Client-side Project Manager, the Client-side Product Manager, Business Analyst, and an external Usability consultant.

Reaction

The Product Owner of your Scrum team needs to be called, as it is a key and important role that should be present. 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 attends the Sprint Review event. He listens and observes everything that happens carefully. 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 discusses these issues with the project manager after the event is over.

Situation

An outside business person asks the team’s Scrum Master 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 in development that can be made available to end-users. These "product increments" must be fully completed for the duration of the Sprint. There should be no hidden work that still needs to be done.

The inspection is carried out on the increment, and any adjustments made aim to create a better and more valuable product.

The Potentially Shippable Product Increment is the version of the product that is inspected and reviewed during the Demo but is often not the real product. It's just "potentially ready".

Without experience in product development, testing, and release processes, one might be left with the impression that the increment is 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 increment 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 ask them first about releasing the product in a real public environment.

When a product is developed for a particular organization, its Product Owner role may have the power to make the release decisions on their own.

The Scrum Master role should not be relevant to both the increment and the released product.

To summarize, the Scrum Master role should not be relevant to this question and should not 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

Shortly after the beginning of the Sprint Review event, the client's product manager brings up the topic about the project’s 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 the Product Owner for comment and advice on the Roadmap of the product.

Reaction

This particular topic should not be brought up during the Sprint Review event, as it is not the aim of the meeting. 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 representative to remain patient and wait til the end of the event.

The Product Owner role can engage in such discussions with the client’s representative if they have the competence to do so. The BVOP recommends all Product Owner roles to be proficient in topics such as budget and future development of the product, as well as participate actively in Roadmap planning.

Situation

The client's product manager does not approve Definitions of Done for one of your User Story and refuses to accept the finished development. Everyone turns to the Scrum Master and Product Owner roles of the Scrum team waiting for a response.

Reaction

The initial spontaneous reaction of most Product Owner or Scrum Master roles would be to satisfy the claims of the business representative who has remarks about various artifacts.

When the product manager is allowed access to the Scrum team’s work materials, another inadvisable situation occurs.

BVOP recommends sharing the Scrum team’s materials with outsiders only if they are competent enough, as this may significantly improve the transparency and collaboration process. Otherwise, delays and waste may result.

It is up to the Scrum team to decide whether they prefer outsiders to have access to their resources. The reason for such shared access would probably be a desire for collaboration and teamwork.

If a productive and collaborative atmosphere is established between the organizations then the described case can be considered valuable and important.

When there is a mutual synergy between the teams of both organizations or there are regulated official rules for material inspection by the other side, the Product Owner role should pay attention to the comments made.

Definitions of Done can be adapted and modified as needed.

Situation

Just before the end of the Sprint Review event, a team member says out loud that a User Story covers all Definitions of Done. However, the finished work is not visually the same as the sketches in the specific Product Backlog.

Reaction

The materials provided in the Product Backlog Items serve as a reference and guidance for the Development Team. Often, there is nothing wrong if the real result doesn’t match with a sketch. 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 been passed successfully, then these positive results show excellent work. If stakeholders also have no claims about the product increment, this is the final indicator of successful work.

The appropriate reaction for this situation would be for all Scrum team members to discuss their way of working and processes.

The following issues related to chapter "Sprint Review" are included in the certification exam. The sequence of questions is presented in the table.
The data is current as of September 7, 2024, 2:53 pm