Event has already taken place!
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 the each sprint cycle.
This is an Informal meeting, No need to prepare Power point slides or any presentation.
This meeting also supports Agile framework as Empirical Model, by Inspect and Adapt. Inspecting the Product Increment and Adapt the Product Backlog.
There is no defined rules for this meeting, But the meeting has to happen during 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.
Though the Scrum Team Members are the only participants of most of the Scrum events, but at Sprint Review the team needs the stakeholders or Business sponsor or Management to showcase the sprint increment.
For this meeting the key stakeholders, Business Sponsor, Management Participates, Those group of people are not fixed for every sprint. Based the scope of each sprint, the participation from management or stakeholder may change.
The Product Owner Invites the key stakeholder in advance. As Product Owner is the bridge between the scrum team and stakeholders or business sponsor, PO is the best person to send the invitation. The stakeholders or Business Sponsors or Management or Customers are the key Recipient of the meeting. And it’s not a one person, most of the time it’s a group of people from different business area.
The Team, primarily the Scrum Master Facilitate the meeting, Schedule it in advance, and set the Scope of the meeting (Explained in details in the next section). Product Owner Cascade down those information to Primary Recipient of the meeting to review the increment (The Stakeholders, Business Sponsor, Customers, Management). So that the Key Recipient can take a decision how important for them to attained the meeting, and may choose to opt out.
The Development Team demonstrate 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 sprint, or reject the increment (Partially or fully) to be deployed.
Sprint Review Meeting is an Informal Meeting, The team don’t need to present any power point presentation of go-through slides. Here the team demonstrates the stories/bug fixes/ technical spikes etc they have worked on through out the current sprint (or just finished sprint). And Stakeholders explains visions and expectations from the team as future sprint deliverable s. 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, where 2 week sprint takes max of 2 Hours and 3 week sprint takes max of 3 hours.
On an average, majority of the sprint review meeting can be concluded in 2 Hours.
for the initial sprints, It may take little longer, as the team is learning about this events, The coach keeps on training the participants about the events and 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 is not have any strict rules. It may be finished early than expected or scheduled, depend upon what are the scopes of demonstration. If the entire scope of the sprint deliverable is demonstrable (functional increment), it may take more time, compared to a team works 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 spend on Introduction, Creating new Backlog Item as key stakeholders request, how much time the team spend Re-prioritization product backlog item 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 little more or less time.
- Get all the functionality demonstrated, and Accepted by Product Owner.
- Identify New Backlog Item (if any)
- Re-Prioritize Product Backlog Item (if required).
- cover all aspect to close & conclude the sprint and get ready for next sprint planning.
The Sprint review meeting is not only a meeting for demonstration, its more than hat. Its 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 Phone or over screen sharing bridge.
Though many of us believe to get the formal acceptance of our sprint deliverable from key Product Owner in sprint review meeting. This is not the meeting for story acceptance for any sprint. Product Owner as a part of scrum team member, works closely with the development team, and during the sprint execution stories get verified and accepted by product owner as on when its ready and meets 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 follow the process properly.
Starting the Meeting – Welcome, Introduction & Set the Context Ready.
Ideally Product Owner starts the conversation by 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 join the meeting for first time and at 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 with is sprint development or Sprint value or deliverable.
As Product Owner is the bridge between new the Scrum team and key stakeholder or business sponsor or end user, Product Owner takes this initiative and roll the ball to start the sprint Review meeting.
Product owner also give a quick explanation on how the team will perform the Sprint review with some basic rules (if any).
Highlight the scope of Demonstration
It’s always good to have awareness of the scope or agenda of any meeting before attending it. For 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 product owner. This can be done by Scrum Master or Product Owner. I personally suggest to have this work done by Scrum Master.
This helps the Stakeholders to decide whether to
- Join the Review Meeting
- Not to Join the Review Meting
- Invite other Management people or Business Sponsor or additional stake holders
There are many ways of circulating the information. Based on my experience I suggest to work on the communication little before than the sprint end. Follow the picture below to understand it better. Where I suggest to have the Scrum Master sends the communication as a form of list one day before the sprint last date to the scrum team including PO, with a prediction of the next day accomplishment.
On the last day, PO confirms the list and invite 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 demonstrate on different order on stakeholders request). The sprint backlog items can have its parent item like feature or epic, that helps categorize the list which increase the readability as per stakeholders interest.
You can have the list based on your team feels is best, keeping stakeholders interest in mind. The columns in image below are self explanatory. The Last column “Will Demonstrate” is to gives a head up that, though the item was part of the sprint backlog, Its plan for not to demonstrated, there can be three main reason for not demonstrating.
- The work item have not completed in constriction or testing and will not be ready for demonstration.
- Its a technical spike or discovery story. And nothing is demonstrable.
- The work item is not so important to demonstrate.
How ever stakeholders can request of those 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 who will demonstrate the story. Product owner or development team member can demonstrate the functionality. Its not necessary one person has to demonstrate all the functionality, it can rotate to several team members. The team experiment sprint over sprint and intelligently figure out the best way to select the person for demonstrating.
Many agile practice have the demonstration for functional increment as their only agenda of sprint review meeting. However there are other important aspects of this meeting, we will learn later in this article.
The demonstration usually happens in a close room with a projector, projecting the screen of demonstrator. Now a day the agile teams are become 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 goto meetings or blue jeans.
The primary goal of the demonstration is to gather feedback from stakeholders or business user to improve quality, discover new product backlog items and directions for future sprints deliverable.
Business Users or Stakeholder may request to demonstrate additional functionality, which may not be the part of current sprint. Those out of scope functionalities use to have relation with the current functionality getting demonstrated. The Team take a quick decision and demonstrate the requested additional functionality.
Discuss Future Sprint Scope
After completion of the demonstration, Product Owner gives a quick summary of current backlog items for next sprint, just to keep every one on same page. This can be done by a quick presentation.
Many times stakeholders discuss about their long term and immediate visions and expectations from the team. That can be covered in 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 expectation from the team , compared with the available product backlog items. The Product Owner may identify new backlog items needs to be created.
The Product Owner or the team don’t need to add those items in backlog then and there. For the interest of every one’s time. The PO along with Scrum team makes the Action item to create new user story, prioritize , groom and plan for 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 condition or business strategy. and vice versa, The stories planned for next sprint or near future, may gets a hold on signal due to the same reason of Market strategy or any other.
The Stakeholders / Business users / Business sponsors may takes the decision and re-prioritize the backlog items to plan for upcoming sprints.
Conclude the Meeting.
Now its time to wrap up the meeting. Few good practice you can follow to wrap up the sprint review meeting.
- Quickly summarize all the discussion points and action points (5 to 10 Min Max)
- Consider a “thank you” to all participants.
- You can also consider a little extra time to appreciate one or two team members, about their great work and contribution.
- Remind every one to participate the retrospective meeting to improve the agile process. (Sprint Review and retrospective are two different meeting)
The Sprint Review meeting is primarily 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 outcome of sprint review meeting. I mentioned below most of them.
- Increment Inspection & adaptive backlog: to support the empirical model of agile inspection is very important, here in this meeting, the functionality increments gets inspected, result to a adaptive product backlog.
- Improve Collaboration: The team get chance to interact with business user and stakeholders, that motivates the team and increase the visibility on the product they are working on.
- Transparent Business Vision : The team get familiar with the vision of the business user and the gets more clarity of the result of the the work they are doing or about to do
- Up to date prioritized Backlog : Re-prioritization helps the team pick the best story for the sprint, that will create the maximum value to the product and business.
- New Backlog Items : This meeting may hatch new product backlog item, to cater with dynamic market trend and competition.
- Team Motivation by Appreciation : Praise of team member by Name motivates the team. and a motivated team always good for self organization and best output.
Once the Sprint Review meeting is over, Its a good practice to do few activities like as below.
- Meeting of Minutes : Its 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 story demonstrated, New Backlog Item Introduced, the change in business vision if any. The details of new priority, mention the team member appreciated and for what.
- New Backlog Item : Product Owner to create user stories in product backlog. and based on the decided priority reorganized them in backlog. If those stories are on immediate need, Scrum Master can schedule a adhoc grooming session, to mature the requirement, and team can estimate the size.
Generally its use to be the next day scheduled for 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 commit in sprint planning meeting next day.
- Re-prioritize : In case of some stories got higher priority as a result of sprint review, those stories may needs grooming to meet the “definition of ready” to plan for next sprint. and also needs grooming.
- Sprint Closure Report : This is optional and not directly related with sprint review meeting. Ideally sprint review meeting happens as a last ceremony of the sprint, some times after Retrospective meeting. So its always a good practice to collaborate your sprint accomplishment as closure report, once your sprint and all its associate ceremonies are over. I will explain on all the Agile reports on some other article.