Articles

The Scrum sprint cycle is a fundamental process in Agile project management, designed to deliver incremental improvements and functional product increments. 

A Scrum Agile Sprint is a time-boxed iteration within the Scrum framework, typically lasting two to four weeks. It's a focused period during which a cross-functional team works to complete a set of user stories and deliver a potentially shippable product increment.

A Sprint Review in SCRUM, is a meeting held at the end of a Sprint where the Scrum team and stakeholders inspect the product increment, review progress, and gather feedback. This event allows the team to demonstrate what has been accomplished during the Sprint and to assess the product backlog and adjust the upcoming plans if necessary. The Sprint Review promotes transparency, adaptation, and collaboration, enabling continuous improvement and alignment with business goals.

A Scrum project often goes through a number of phases. Five phases, composed of nineteen processes, are suggested in A Guide to the Scrum Body of Knowledge (SBOK®). After the Implement phase comes the Review and Retrospect phase.

This phase includes two processes that focus on reviewing the deliverables and work that has been done and determining ways to improve the practices and methods used to do project work. It is important to note that the processes are not necessarily performed sequentially or separately. At times, it may be more appropriate to combine some processes, depending on the specific requirements of each project.

Demonstrate and Validate Sprint

In this process, the Scrum Team demonstrates the Sprint Deliverables to the Product Owner in a Sprint Review Meeting. The purpose of this meeting is to secure approval of the Sprint User Stories by the Product Owner. This process is not only an important quality element in a Scrum project, but it is also a key element to maintain stakeholder engagement. The business stakeholders are encouraged to participate in the Sprint Review Meeting to gain first-hand knowledge of the Product or Service and its progress, and to provide feedback. Business stakeholder feedback is an important input to future Sprints.

Accepted Deliverables may be released to the customer if so desired. A list of Accepted Deliverables is maintained and updated after each Sprint Review Meeting. Deliverables that do not meet the Acceptance Criteria are called Rejected Deliverables. User Stories associated with Rejected Deliverables get added to the Prioritized Product Backlog so they can be considered as part of a subsequent Sprint to rectify any issues. This is highly undesirable because the objective of every Sprint is for the deliverables to meet the criteria for acceptance.

Retrospect Sprint

In this process, the Scrum Master and Scrum Team meet to discuss the lessons learned throughout the Sprint. This information is documented as lessons learned which will be applied to future Sprints. As a result, there may be agreed actionable improvements or updated Scrum Guidance Body Recommendations. This process is an essential component of the continuous improvement in Scrum.

Agreed Actionable Improvements are the primary output of this process. They are the list of actionable items that the team has created to address problems and improve processes in order to enhance their performance in future Sprints. Once the Agreed Actionable Improvements have been elaborated and refined, the Scrum Team may consider action items to implement the improvements. The Retrospect Sprint Log is a record of the opinions, discussions and actionable items raised in a Retrospect Sprint Meeting. The Scrum Master could facilitate creation of this log with inputs from Scrum Core Team members. The collection of all Retrospective Sprint Logs becomes the project diary and details project successes, issues, problems and resolutions. The logs are public documents available to anyone in the organization.

Following the three processes of the Review and Retrospect phase helps those involved in a Scrum project to review deliverables and identify impediments to neutralize in the future. Remember that the processes do not need to be performed sequentially or separately. They can be adjusted to complement the specific requirements of each project. Before leaving the Review and Retrospect phase, however, it is imperative to analyze the project and determine what worked and what didn’t work.