Sprint Review is one of the official events in the Scrum framework. In this article, we will present real examples related to the Sprint Review event and how you can approach different problems and situations.
The Sprint Review event is one of the most important events as it completes the completed sprint. Reference: “Sprint Review, What is Sprint Review meeting (event) in Scrum”, https://bvop.org/learnagile/sprint-review/#:~:text=A%20Sprint%20Review%20meeting%20is,the%20Product%20Backlog%20if%20needed.&text=Sprint%20Review%20is%20a%20Scrum,the%20end%20of%20a%20Sprint.
Real examples of the Sprint Review event in Scrum
Your colleague, a beginner Scrum Master, asks you a question. He asks you if, for their 3-week sprints, they can accept the Sprint Review event lasting 2 and a half hours.
The scrum master is a beginner, it is somewhat normal that he still does not understand some things, is not sure, and needs additional information and advice.
From my point of view, the Scrum Master should explain to a colleague that each Sprint is individual, a person outside the team who does not know the product and the development process cannot and should not give advice on working on a product he does not know, but he can help with information on how, in theory, Scrum events should take place. Reference: “The Scrum framework how and when to use it with Scrum teams”, https://www.yahowto.com/scrum-framework/
If the sprint is 3 weeks, the duration of the Sprint Review event should be no more than 3 hours, ie in reality 2 and a half hours are eligible for this meeting.
But a novice colleague should keep in mind that he is responsible for respecting the time limit of the event, he should make sure all participants focus on the main issues to be discussed at this meeting and to achieve the goal of the event (increment presented), received feedback, constructive discussion with prioritized Product Backlog).
That is, the Scrum Master must tell the colleague that a duration of 2 and a half hours is allowed for the Sprint Review event if the sprint is 3 weeks, but to avoid the risk that this meeting will not achieve its goal, it would be wiser to accept a duration from 3 hours, especially if the colleague is a beginner Scrum Master and does not have enough experience.
Let’s note that after preparing these questions you will have a chance to successfully pass the exam for each Scrum Master certification. Reference: “Best Scrum Master Certifications for 2021 and 2022”, https://eduwiki.me/best-scrum-master-certifications-for-2021-and-2022/
Participants in the Sprint Review event
You gather at the usual place for your Sprint Review event. Attendees are You as the Scrum Master, the development team without a new budding colleague, the Project Manager from the client, their Product Manager, Business Analyst, and a hired external usability consultant.
The meeting was not attended by the Product Owner role and a new budding colleague.
In any case, the meeting must take place, because the Scrum Master must in the future encourage team members to personally attend the Scrum event. Reference: “Who are the Scrum Developers?”, https://scrumtime.org/scrum-developers/
The absence of a new beginner colleague is not fatal, after the meeting the other team members can share with him the necessary information. Because the absence of a Product Owner role can be a problem.
The increment can also be presented by other team members, but questions may arise about the Definitions of Done of the items, the adaptation of the product, etc.
If the team is well self-organized and competent, it should cope with this situation. It would be good to write down all the remarks on the increment, to discuss the wishes and comments of the client about the upcoming work, to choose the items that have a higher priority.
This information should be passed on to the Product Owner role, he can further contact the customer to discuss the nuances.
Because the Scrum Master has to explain to the team that such situations, when there is no personal presence of the participants, which have an important influence on how the product will be developed, are not welcome. This carries the risk of errors, irregularities, and loss of time.
A project manager from your organization came to your Sprint Review event. He listens carefully and watches. He is pleased that the work is going well. Finally, he turns to you and asks you when you expect as a guide to releasing the latest finished developments to a real product in a living environment.
The Sprint Review event discusses issues such as the current 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).
Because it should be explained to the Project Manager that the information about the release of the latest finished developments is only an assumption based on the current state of the product backlog.
This information can only be used as a guide because after each sprint things can change. You can use the team’s Velocity value, view the Backlog, and collect Story Points on the items.
Thus, there will be an idea (as a guide) of how long it takes to release the latest finished developments to a real product in a living environment.
The topic of the project budget during the Sprint Review event
The Sprint Review event begins. Shortly after greeting each other, the customer’s product manager opens a topic about the project budget. He is not sure if his organization’s resources will be enough to continue working on the product for another 6 months. Ask your Product Owner for comments and advice on their Roadmap.
In this situation, the Scrum Master should gently ask the customer’s product manager to discuss this issue at the end of the event or even after it if there is no time.
The Scrum Master role takes care of meeting the duration and achieving the goal of each Scrum event.
During the Sprint Review, you should review what exactly has been achieved during the sprint, inspect the product increment, adapt the product backlog, and accept useful feedback for the next sprint. These are the most important moments. Reference: “Scrum example team and projects scenarios”, https://phron.org/scrum-example-team-and-projects-scenarios/
The topic of the project budget is also important, but you should not plan for 6 months ahead, because after each sprint and each increment things can change drastically.
In any case, the Scrum Master must ensure that the meeting is held in such a way that the focus will first be on the more important issues and discussions, to respect the duration and achieve the goal of the event, on the other hand, and the customer’s product manager. to obtain the necessary information.
Scrum team, stakeholders, and feedback
At the Sprint Review event, business people and all representatives outside your Scrum team review what has been achieved and inform you that they have no questions or any other comments or suggestions, and prepare to leave the meeting.
The Scrum Master Role must ensure that the meeting takes place and that all participants understand the purpose of the event. Reference: “Scrum Master role and issues related to the team and project work”, https://w-europe.org/scrum-master-role-and-issues-related-to-the-team-and-project-work/
The purpose of the Sprint Review event is not only to present an increment and review of the achieved but also received feedback, constructive discussion with a prioritized Product Backlog, current Release Plan.
The Scrum Master should ask business people and all representatives outside the Scrum team to continue the meeting and discuss all issues.
Transparency, inspection, and adaptation are needed to develop a quality product that will bring business value.
After reviewing the increment, the discussion of the Product Backlog items, which are arranged at the top of the backlog list, usually begins logically.
After the demonstration, stakeholders can suggest some logical ideas for work or have ideas for important refinement, which need to happen right after the demo (during the next sprint).
The Scrum Master must explain how important it is to do all this because it directly affects how the product will be developed in the next sprint. Reference: “Professional Scrum Master vs Professional Scrum Developer”, https://stc-montreal.org/professional-scrum-master-vs-professional-scrum-developer/
Of course, the Product Owner role can receive a lot of additional information, comments, remarks, or questions after the event, but if the Scrum team is present, it has the opportunity to observe various moments and spontaneous reactions, impressions, and comments of the client.
This can be more valuable than presenting analytically ordered information after the review, as the team can capture nuances.
The Sprint Review event may also include additional discussions. Topics of conversation can be indicative forecasts of time, budget and costs, market dynamics, consumers and potential new opportunities, and the business value of the product.
The Scrum Master must make sure that all these issues are discussed during the Sprint Review event, which will bring clarity to the work process in the next sprint.
All parties are interested in achieving good results, so it would be wiser to discuss all the details in advance than to correct the mistakes that lead to a waste of time, effort, and budget.
More on the topic: “Free training to prepare for the Scrum Master Certification exam”, https://www.islandjournal.net/scrum-master-certification-exam/
Demonstration of the increment before the end of the sprint
Your client’s Account Manager will contact you and ask if you can demonstrate your product one day before the end of your sprint because they need to prepare presentations.
In my opinion, in this situation, the Scrum Master should insist that a demonstration of the product be done right at the end of the sprint, as planned.
He must explain to the Client’s Account Manager how important it is to observe the fixed time of each sprint, and it is also likely that the team will not be able to provide a completed increment one day before the end of the sprint. Reference: “Scrum Sprint Review meeting Questions and Answers”, https://www.policymatters.net/scrum-sprint-review-meeting-questions-and-answers/
Any disturbance in the course of the work of the Scrum team can negatively affect the subsequent work, the speed of the team will not be measured accurately, the rhythm will be disturbed, and these are the things that should be avoided.
External Product Manager
Your customer’s product manager disapproves of Definitions of Done for one of your User Stories and refuses to accept work on it. Everyone is staring at you, including your Product Owner.
In this situation, the Scrum Master should ask the Product Owner for assistance.
The role of the Scrum Master role does not include accepting or rejecting the work done, but he must take care of all parties and strive to follow the order, rules, and principles of Scrum.
Although the Product Owner is staring, the Scrum Master should ask him to think about it, because officially the Product Owner role during this event accepts or rejects the work done, referring to the definitions.
It may turn out that the item does not respond or, conversely, responds, but the customer’s product manager has some misconception, however, when planning work on the sprint all the details are discussed with stakeholders, Definitions of Done for each User Story is determined after the Product Owner (who represents the “stakeholder voice” to the team and is responsible for creating value coming from the work of the Development team) receives the necessary information to develop each item. Reference: “Certified Scrum Master vs Professional Scrum Master”, 2029, https://wikipedia-lab.org/certified-scrum-master-vs-professional-scrum-master/
In my opinion, the Product Manager of the client should explain why he does not approve Definitions of Done for a User Story, where there is a problem, and the Product Owner should decide to declare the item incomplete or not.
Most likely in this situation, the Product Owner will return an incomplete User Story to the product backlog with priority at its discretion and it is logical to be arranged for the next sprint.
New project plans and sharing product backlog items
One day before your Sprint Review event, your client’s Account Manager contacted you and explained that they were working with their Marketing Department to prepare new plans. He asks you to send him the items that your team will complete during the sprint.
In this situation, the Scrum Master must explain that before the Sprint Review event, it is very risky to make plans for the next sprint.
During the Sprint Review meeting, a review is made of what exactly was achieved during the sprint, the product increment is inspected, after receiving feedback for the next sprint, the product backlog is adapted.
During this event many things can change, it may turn out that some items are dropped, or new ones are added, the priority of the items may change, and so on.
The adaptation of the increment directly depends on the inspection. The Scrum Master must ask the Client’s Account Manager to wait another day and then he will receive the necessary information.
The Scrum Master could use the Velocity value of the team from the last sprint, look at the Backlog and collect the Story Points of the items at the top of the list, but I think this information would be very unreliable and indicative, it is more reasonable to wait for the end of Sprint Review Meeting.
Read more: “Free preparation for the Scrum Master certification exam (CSM, PSMI, PSMII, BVOP)”, https://brightonbot.com/preparation-scrum-master-certification-exam/
You have already presented your increment at the Sprint Review meeting. Product Backlog items have been officially announced as completed. There is no work left unfinished. Everyone looks happy. Business people offer, as everything is fine, to discuss possible promotions of team members who have performed well, and then want to take you for a drink.
In my opinion, in this situation, the Scrum Master should suggest that the drink be made outside working hours, however, a waste of time leads to negative consequences.
Also, discussing possible promotions for team members who have performed well is a delicate moment.
If one team member gets a promotion and another doesn’t (because he thinks he deserves it), it can lead to an imbalance in the team, on the other hand, it can also stimulate more effort. It all depends on the team and the situation.
In my opinion, the management should solve such issues as promotions of the team members.
A team member shares issues with User Story
Shortly before the Sprint Review event, a team member told you that User Story covers all definitions of completeness, but the finished work visually differs from the sketches included in the Product Backlog item.
In this situation, the Product owner role must be informed. In any case, the Sprint Review event must be held and a product that we already have must be demonstrated, even if it visually differs from the sketches.
The meeting will be attended by stakeholders who will also express their views, it may turn out that this discrepancy is not significant.
Because in this situation, the Product Owner must decide whether to accept or reject the work done, referring to the definitions.
If he decides that the work is not completed, then this User Story returns to the product backlog with priority at his discretion.
It should also be discussed why this discrepancy occurred, especially if User Story covers all definitions of completeness.
It may be that the Product Owner’s role responsible for the Product Backlog did not provide enough information or the Sprint planning was not done properly.
The Scrum Master must ensure that the Sprint Review event is conducted following the Scrum rules, protect the team, and assist if there is any ambiguity or lack of information. Reference: “Scrum Master issues related to the Sprint Review event”, https://www.nebraskasocialstudies.org/scrum-master-issues-related-to-the-sprint-review-event/
Project Manager, Product Owner, and Sprint Review event
While browsing the Product Backlog items, the customer project manager interrupts the conversation and asks a question to your Product Owner. He asks him why two very similar items are rated with Story Points 3 and 13. Your product is looking at you.
One of the tasks of the Scrum Master role is to provide information about the Scrum way of working. Reference: “Scrum problems with questions, answers and explanations from the point of view of Scrum Master”, https://ossalumni.org/scrum-problems-explanations-from-scrum-master/
This question of the client’s project manager cannot be ignored and it would be good to briefly explain why two very similar items are rated with Story Points 3 and 13.
On the other hand, the scrum master must monitor the duration of the sprint to be observed. , if he feels that there is not enough time for a detailed explanation, he should ask to talk about the issue after the meeting.
It should be explained to the project manager that Story Points determines the team, Planning Poker is made – a game technique through which the team puts time ratings on the items for the upcoming sprint, “playing them on poker”.
Sometimes it happens that the items only look similar, especially to outsiders, but after Planning Poker it turns out that many details matter a lot.
Team members discuss, share experiences, where a problem may arise in the development of the item, and as a result reach some consensus, usually choosing a mean value from the proposed Story Points.
The Scrum Master should ask for the assistance of the Development team if the client’s project manager still has doubts.
They know best their skills, knowledge of technology, level of competence, for which they can provide a more detailed explanation. Reference: “Why do you want to be a certified Scrum Master?” by Rita Gavelis, https://www.mmrls.org/why-certified-scrummaster/
The Scrum Master should strive to ensure that the duration of the meeting is observed, all participants focus on the issues that lead to the goal of this event, but on the other hand to provide information on the issue to the project manager of the customer because it is normal that stakeholders sometimes do not understand any scrum details.