Sprint Review Meeting

What is Sprint Review Meeting 

Sprint Review Meeting also known as Sprint Demonstration usually held on the last day of the sprint to demonstrate the accomplishment from the specific sprint commitment. Product Owner from many Agile practices, also review the completed story and mark them as Done or Not Done based on “Definition of Done”. This Meeting is the realization phase of each sprint cycle. This is an Informal meeting, No need to prepare Powerpoint slides or any presentation.

This meeting also supports the Agile framework as Empirical Model, by Inspect and Adapt. Inspecting the Product Increment and Adapting the Product Backlog.

There are no defined rules for this meeting, But the meeting has to happen at end of every sprint to have the green signal from the Product Owner or stakeholder for the potentially ship able increment, which was constructed during the sprint.

Participants of Sprint Review Meeting 

Though the Scrum Team Members are the only participants of most of the Scrum events, at Sprint Review the team needs the stakeholders Business sponsors, or Management to showcase the sprint increment. For this meeting, the key stakeholders, Business Sponsors, Management Participates, and Those groups of people are not fixed for every sprint. Based on the scope of each sprint, the participation of management or stakeholder may change . . The Product Owner Invites the key stakeholder in advance. As the Product Owner is the bridge between the scrum team and stakeholders or business sponsors, PO is the best person to send the invitation to. The stakeholders Business Sponsors Management or Customers are the key Recipients of the meeting. And it’s not a one-person, most of the time it’s a group of people from different business areas.

The Team, primarily the Scrum Master Facilitates the meeting, Schedule it in advance, and sets the Scope of the meeting (Explained in detail in the next section). Product Owner Cascade down that information to the Primary Recipient of the meeting to review the increment (The Stakeholders, Business Sponsor, Customers, Management). So that the Key Recipient can take a decision on how important for them to attained the meeting, and may choose to opt out.

The Development Team demonstrates the stories one by one as planned. Or can change the sequence on Product Owner request or on key meeting recipients request.

The Stakeholders review the increments, Accept increment(s), suggest new changes for future sprints, or reject the increment (Partially or fully) to be deployed.

Time Box of Sprint Review Meeting 

Sprint Review Meeting is an Informal Meeting, The team doesn’t need to present any PowerPoint presentation or go-through slides. Here the team demonstrates the stories/bug fixes/ technical spikes etc they have worked on throughout the current sprint (or just finished sprint). And Stakeholders explain visions and expectations from the team as future sprint deliverables. Typically the time takes to complete the meeting is 1 Hr per week of the sprint duration. what that means is, if a sprint is 1 week long, the team can complete the meeting in 1 hour, whereas a 2-week sprint takes a max of 2 hours and a 3-week sprint takes a max of 3 hours. On average, the majority of the sprint review meeting can be concluded in  2 Hours. for the initial sprints, It may take a little longer, as the team is learning about these events, The coach keeps on training the participants about the events and the best use of scrum values, keeping in mind the Empirical Model to implement the Inspect and Adapt.  And later the team become more mature and learned to optimize the time for each event including sprint review. The duration does not have any strict rules. It may be finished early than expected or scheduled, depending upon what are the scopes of the demonstration. If the entire scope of the sprint deliverable is demonstrable (functional increment), it may take more time, compared to a team working on functional increment mixed with Technical spikes and bug fixing. Technical Spikes are most of the time not demonstrable to key stakeholders, hence the overall sprint review in this case will take less time as the sprint have less functionality to demonstrate than the team can do.

Secondly apart from functional demonstration, how much time the team spends on Introduction, Creating new Backlog Items as key stakeholders request, how much time the team spends on Re-prioritization product backlog items also influence the total time for the sprint review.

So don’t stick to the duration, Target for 2 Hours, but getting the objective of the meeting fulfilled is primary, it may take a little more or less time.

1. Get all the functionality demonstrated, and Accepted by the Product Owner.
2. Identify New Backlog Item (if any)
3. Re-Prioritize Product Backlog Item (if required).
4. cover all aspects to close & conclude the sprint and get ready for the next sprint planning.

How Sprint Review Meeting Works

The Sprint Review meeting is not only a meeting for demonstration, it’s more than that. It’s an informal meeting. All participants can get together with Tea/coffee and get the advantage of being co-located, If the agile team is distributed, they can join the meeting on the Phone or over screen sharing bridge.

Though many of us believe to get the formal acceptance of our sprint deliverable from key Product Owners in the sprint review meetings. This is not the meeting for story acceptance for any sprint.  Product Owner as a part of the scrum team member works closely with the development team, and during the sprint, execution stories get verified and accepted by-product owner when it’s ready and meet the “Definition of Done”.

So It’s not only a formal sign-off meeting based on demonstration. Let’s learn how we can conduct this meeting and its details.

Scrum Master is the local coach for the team. He/she needs to make sure it happens and everyone follows the process properly.

Starting the Meeting – Welcome, Introduction & Set the Context Ready

Ideally, the Product Owner starts the conversation with a quick welcome message to

all participants. Followed by a casual and brief introduction between new participants. There may be new stakeholders or business sponsors joining the meeting for the first time and on the other side, the development team can have new team members. It’s always good to have a quick introduction between all the new participants. Mentioning the information about who’s who and how he/she is involved is sprint development or Sprint value or deliverable.

As the Product Owner is the bridge between new the Scrum team and key stakeholder or business sponsor or end-user, the Product Owner takes this initiative and roll the ball to start the sprint Review meeting.

The product owner also gives a quick explanation of how the team will perform the Sprint review with some basic rules (if any).

Highlight the scope of the Demonstration

It’s always good to have awareness of the scope or agenda of any meeting before attending it. For the Sprint Review meeting also Product Owner mentioned the details of the functionality that will be demonstrated, and some other changes the team has made but not planned for any demonstration, or may not be demonstrable, like technical spikes or discovery story. It’s a good practice to circulate the sprint review demonstration scope for each sprint, 1 or 2 days in advance to the product owner. This can be done by Scrum Master or Product Owner. I personally suggest having this work done by Scrum Master

This helps the Stakeholders to decide whether to

1. Join the Review Meeting
2. Not to Join the Review Meeting
3. Invite other Management people Business Sponsor or additional stakeholders

There are many ways of circulating information. Based on my experience I suggest working on the communication a little before the sprint end. Follow the picture below to understand it better. Where I suggest having the Scrum Master send the communication as a form of a list one day before the sprint’s last date to the scrum team including PO, with a prediction of the next day’s accomplishment. On the last day, PO confirms the list and invites associated stakeholders by sharing the list as a heads up.

The same list PO also reiterate at the beginning of the sprint review meeting.

Below attached a template you can use to articulate the scope. It has a list of all sprint backlog items, in a sequence, it will be demonstrated (however items can be demonstrated in a different order on stakeholders’ request).  The sprint backlog items can have their parent item like feature or epic, which helps categorize the list and increase the readability as per stakeholders’ interests. You can have the list based on what your team feels is best, keeping stakeholders’ interests in mind. The columns in the image below are self-explanatory. The Last column “Will Demonstrate” is to give a head-up that, though the item was part of the sprint backlog, Its plan for not to demonstrate, there can be three main reasons for not demonstrating.

1. The work item has not been completed in constriction or testing and will not be ready for demonstration.
2. It’s a technical spike or discovery story. And nothing is demonstrable.
3. The work item is not so important to demonstrate.

However, stakeholders can request that item during sprint review to demonstrate.

Demonstrate the new functional Increments

This is the main part of the meeting, where the functionality increment gets demonstrated by the scrum team. There is no strict rule for who will demonstrate the story. The product owners or development team members can demonstrate the functionality. It’s not necessary for one person to demonstrate all the functionality, it can rotate to several team members. The team experiments sprint over sprint and intelligently figures out the best way to select the person for demonstration. Many agile practices have the demonstration for functional increment as their only agenda of sprint review meetings. However, there are other important aspects of this meeting, which we will learn later in this article. The demonstration usually happens in a closed room with a projector, projecting the screen of the demonstrator. Now a day agile teams are becoming more distributed, where gathering in one room is practically not possible, however in situations like this, it can be done through screen sharing using any meeting collaboration tools like WebEx or Skype or going to meetings or blue jeans. The primary goal of the demonstration is to gather feedback from stakeholders or business users to improve quality and discover new product backlog items and directions for future sprint deliverables. Business Users or Stakeholders may request to demonstrate additional functionality, which may not be part of the current sprint. Those out-of-scope functionalities use to have related to the current functionality getting demonstrated. The Team takes a quick decision and demonstrates the requested additional functionality.

Discuss Future Sprint Scope

After completion of the demonstration, the Product Owner gives a quick summary of current backlog items for the next sprint, just to keep everyone on the same page. This can be done by a quick presentation. Many times stakeholders discuss their long-term and immediate visions and expectations from the team. That can be covered in the next couple of sprints by the scrum team and increment the product functionality to meet the Business User or stakeholders’ vision or goal. The Product Owner is well aware of the current backlog health and its clarification maturity. The Product Owner can express that he/she needs further clarification offline from the stakeholders to mature up the backlog and requirement clarification keeping the business vision in mind. That meeting happens outside of the sprint review meeting.

Identify New Backlog Item

After the discussion on product vision and immediate expectations from the team, compared with the available product backlog items. The Product Owner may identify new backlog items that need to be created. The Product Owner or the team doesn’t need to add those items to the backlog then and there. For the interest of everyone’s time. The PO along with the Scrum team makes the Action item to create a new user story, prioritize, groom, and plan for the best possible future sprint.

Re-Prioritize Backlog Item

The functionalities or features identified for future execution, currently at the bottom of the product backlog with low priority, can get high priority based on market conditions or business strategy. and vice versa, The stories planned for the next sprint or near future, may get a hold on the signal due to the same reason of Market strategy or any other. The Stakeholders / Business users / Business sponsors may take the decision and re-prioritize the backlog items to plan for upcoming sprints.

Conclude the Meeting.

Now it’s time to wrap up the meeting. Few good practices you can follow to wrap up the sprint review meeting.

1. Quickly summarize all the discussion points and action points (5 to 10 Min-Max)
2. Consider a “thank you”  to all participants.
3. You can also consider a little extra time to appreciate one or two team members, for their great work and contribution.
4. Remind everyone to participate in the retrospective meeting to improve the agile process. (Sprint Review and retrospective are two different meetings)

Potential Outcome of Sprint Review Meeting

The Sprint Review meeting is primarily to establish a feedback loop for any scrum team. Which always helps the team to improve on quality, process, and value.

There are many direct indirect benefits and outcomes of sprint review meetings. I mentioned below most of them.

1. Increment Inspection & adaptive backlog: to support the empirical model of agile inspection is very important, here in this meeting, the functionality increments get inspected, resulting in an adaptive product backlog.
2. Improve Collaboration: The team gets a chance to interact with business user and stakeholders, which motivates the team and increase the visibility of the product they are working on.
3. Transparent Business Vision: The team gets familiar with the vision of the business user and gets more clarity on the result of the work they are doing or about to do
4. Up to date prioritized Backlog: Re-prioritization helps the team pick the best story for the sprint, that will create the maximum value for the product and business.
5. New Backlog Items: This meeting may hatch new product backlog items, to cater to dynamic market trends and competition.
6. Team Motivation by Appreciation: Praise of team member by Name motivates the team. and a motivated team is always good for self-organization and best output.

Post Sprint Review Meeting Activity

Once the Sprint Review meeting is over, It’s a good practice to do a few activities like as below.

1. Meeting of Minutes: It’s always a good practice to send a meeting summary, Scrum Master can circulate a meeting of minutes to all participants and also to the person invited or involved but unable to attend the meeting. The summary can include, All stories demonstrated, New Backlog Item Introduced, and the change in business vision if any. The details of new priority, mention the team member appreciated and for what.
2. New Backlog Item: Product Owner to create user stories in the product backlog. and based on the decided priority reorganized them in the backlog. If those stories are in immediate need, Scrum Master can schedule an Adhoc grooming session, to mature the requirement, and the team can estimate the size.
   Generally, it used to be the next day scheduled for a sprint planning meeting, so if there are some functionalities identified for the next sprint, those functionalities must be available with all necessary details to meet the “definition of ready” as a form of user story in Product Backlog. So that it can be committed in the sprint planning meeting the next day.
3. Re-prioritize: In case of some stories got higher priority as a result of the sprint review, those stories may need grooming to meet the “definition of ready” to plan for the next sprint. and also needs grooming.
4. Sprint Closure Report: This is optional and not directly related to sprint review meetings.  Ideally, a sprint review meeting happens as a last ceremony of the sprint, sometimes after the Retrospective meeting.  So it’s always a good practice to collaborate your sprint accomplishment as a closure report, once your sprint and all its associate ceremonies are over. I will explain all the Agile reports in some other articles.