How Are Sprint Review Meetings Different From Sprint Retrospective Meetings In Scrum?

The primary objective of a sprint review meeting is to present the development work carried out by the development team, avail proper and reliable feedback regarding the work completed until then, and support collaboration. The review meetings are a part of the inspecting and adapting process associated with scrum. Scrum methodology supports self-correction and self-learning methods. There are several processes, which help the team to self-correct, and find where the project is heading. Both the sprint review and the sprint retrospective meetings are conducted after a particular sprint is completed. It is important not to get confused between the two.

Sprint review meeting
Sprint reviews are informal meetings, and specially conducted to present the work – user stories and development tasks – carried out and completed by the team members during the sprint. The work completed is ideally demonstrated in the form of a “demo” to the stakeholders and investors. The main idea is to put the completed work in front of individuals who have invested into the project, so they can get an idea regarding the quality and the quantity of development carried out. It helps to increase the user participation levels. The stakeholders can subsequently accept the work, reject it if they are not satisfied, or if the work does not adhere to the acceptance levels as specified at the time of creating the product backlog items. The product owner represents the stakeholders’ interests, and he or she decides about the work during the meeting. In reality, the stakeholders may attend the meeting, but they are passive attendees and are not allowed to speak or volunteer opinions during the review. The product owner does all the talking.

Goals

• Present the sprint development work to the product owner
• Get the user stories and tasks accepted as “Done”
• Rejected and incomplete tasks to be transferred back to the product backlog

Who attends?
Product owner, team members, scrum master, stakeholders (only if interested)

Time boxed to
1 hour per week of the sprint duration/length
(I.e. for a 2-week sprint, the time to be allotted = 2 hours for the meeting and for a 4-week sprint = 4 hours, and so on…)

Sprint retrospective meeting
The entire team, product owner, and the scrum master ought to put in efforts to find out about what lessons need to be learnt from prior sprints, what more can be done to streamline the sprint process, and what kind of pitfalls and problems are likely to arise in the future and how they can affect the project.   

Goals

• What can and should be learnt from the sprints already completed
• Identify potential pitfalls and impediments likely to affect the team during the sprint activity
• Plan for the next sprint cycle
  

Who attends?
Product owner, team members, and the scrum master

Time boxed to
3 hours

Find out more, and download our free QuickScrum tool which can help you in implementing scrum in an effective and profitable way!

Report this Page