A Scrum Sprint in Agile is a time-boxed iteration, typically lasting two to four weeks, during which a Scrum team works to complete a set of prioritized tasks from the Product Backlog. Each Sprint begins with a Sprint Planning meeting, where the team commits to specific goals and outlines the work to be done. Daily Scrum meetings are held to track progress, address challenges, and adjust plans as needed. At the end of the Sprint, the team conducts a Sprint Review to demonstrate the completed work to stakeholders and gather feedback. The Sprint concludes with a Sprint Retrospective, where the team reflects on their performance and identifies areas for improvement. This iterative process enables continuous delivery of valuable, incremental improvements to the product, fostering adaptability and responsiveness to changing requirement.

The Sprint Review is a crucial event in the Scrum framework that occurs at the end of each sprint. This meeting provides an opportunity for the Scrum Team and stakeholders to inspect the increment, gather feedback, and collaborate on what to work on next. The goal of the Sprint Review is to foster transparency and adapt the product backlog based on insights and feedback, ensuring the project aligns with customer expectations and business objectives. In this collaborative session, the team demonstrates the work completed, discusses what went well, and identifies areas for improvement, ultimately driving continuous improvement and product evolution.

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 the Retrospect Sprint process. This is a list of actionable items that the team has come up with to address problems and improve processes in order to enhance team performance in future Sprints. Once the agreed actionable improvements have been elaborated and refined, action items to implement the improvements may be assigned by the Scrum Team and each action item will have a defined due date for completion. The Retrospect Sprint Log is a record of the opinions, discussions, and actionable items raised in a Retrospect Sprint Meeting. The Scrum Master usually facilitates creation of this log with input from Scrum Core Team members. The collection of all Retrospective Sprint Logs becomes the project diary, which includes details on project successes, issues, problems, and resolutions. These logs are public documents available to anyone in the organization. 

Following the two 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.

Primary objectives of the meeting are to identify three specific things:

1. Things the team needs to keep doing: best practices
2. Things the team needs to begin doing: process improvements
3. Things the team needs to stop doing: process problems and bottlenecks

Other tools used in the Process of Retrospect Sprint are:

1. ESVP
2. Speed Boat
3. Metrics and Measuring Techniques
4. Scrum Guidance Body Expertise

The outputs of the Retrospect Sprint are:

1. Agreed Actionable Improvements
2. Assigned Action Items and Due Dates
3. Proposed Non-Functional Items for Prioritized Product Backlog
4. Retrospect Sprint Log(s)
5. Scrum Team Lessons Learned
6. Updated Scrum Guidance Body Recommendations

How is the Retrospect Sprint Meeting related to the ‘inspect-adapt’ aspect of Scrum?

The Retrospect Sprint Meeting is an important element of the ‘inspect-adapt’ Scrum framework and it is the final step in a Sprint. All Scrum Team members attend the meeting, which is facilitated or moderated by the Scrum Master. It is recommended, but not required for the Product Owner to attend. One team member acts as the scribe and documents discussions and items for future action. It is essential to hold this meeting in an open and relaxed environment to encourage full participation by all team members. Discussions in the Retrospect Sprint Meeting encompass both what went wrong and what went right.

One of the questions which throw a curveball into the diligent efforts of the Scrum community to introduce Scrum Framework is:

How long should it be?

In Agile methodologies, a Scrum Sprint is a time-boxed iteration during which a Scrum team works to deliver a potentially shippable product increment. Typically lasting between one to four weeks, Sprints allow teams to focus on a set of prioritized features or user stories, ensuring steady progress and frequent delivery of value. The Sprint begins with Sprint Planning, where the team selects items from the product backlog to work on. Throughout the Sprint, daily stand-up meetings keep the team aligned, while the Scrum Master helps remove any impediments.

Why should there be a fixed length to Sprints?

After all, Scrum is about adapting to change; poorly chosen Sprint length will lead to impatient management, overburdened Scrum Team and ultimately, bad Project output. Variable Sprint Length seems like a magic bullet that will enable work according to the Real word conditions as expected now rather than anticipated for later. Sprint planning now becomes easier. One does not have to overanalyze whether to include or exclude one more week which will bring the Product to a better Stage after every Sprint but make the process less flexible. Why are we not seeing more Vari-time Sprinting?

The Primary reason why we do not have this is because of two words: Time-Boxing. It is a principle of Scrum where which proposes fixing a certain amount of time for each process and activity in a Scrum project (Source: SBOK). It Brings Discipline. In Scrum, Instead of filling pages of Forms and Progress reports, the Scrum team members can avoid Status Meetings and focus on working. The cost of doing that is the Discipline of time-boxing. So the Middle Management guys know that they will get timely data to do their number crunching without bothering the Project team. Timely Feedback and Status reports can be sent to external Clients who will then slowly release the next installment of payment.

Now that we have established that Fixed Sprint length is necessary, what is the Ideal Length?

The Simple Trite Answer is “It Depends”, but on what? Some factors are: Size of Company, how much testing is required, the amount of “Creativity” required and the nature of clarity and change in the project. Larger organizations have a greater need for Documentation (so all relevant people know what is happening) and longer term planning thus necessitating longer Sprint Lengths. Early Stage Startups should have short Sprint Lengths as they need to accelerate their learning curves and adapt their offering to fit what the market wants. Everyone already knows what is happening in the organization and the project could be dead by next financial year if the offering is not refined this week. Creativity requires time to come up with an Idea and not the rush of deadline looming. Stable project parameters allow for longer Sprints of 4 to 6 weeks. If project requirements are themselves not clear, shorter Sprints of 1 to 4 weeks are warranted.

Ultimately, however, the most important question is: what is the Scrum Team actually comfortable with? This brings us to another important Principle: Self-Organization. The Team should buy-in and say: “We are going to have X week Sprint” Let the Scrum team members do the above analysis themselves and come up with a Sprint Length without pushing it on them.