Sprint Retrospective. Guidelines

4 min readOct 28, 2022

A Sprint Retrospective is a meeting held after the sprint review and before the next sprint planning.

The Sprint Retrospective aims to plan ways to increase quality and effectiveness. The Development team (may be Scrum teams or others) inspects how the last iteration went concerning individuals, interactions, processes, tools, and their Definition of Done. The Sprint Retrospective concludes the iteration.

During the Sprint Retrospective, the team discusses:

What went well in the Sprint
What could be improved
What will we commit to improve in the next Sprint

Guideline

Retrospective meetings should be time-boxed. In Scrum, it is a maximum of three hours for one-month iterations. For shorter Sprints/iterations, the event is usually shorter.

Regular agile retrospectives are a cheap, fast, and effective way for project teams to improve continuously. They:

Provide dedicated time to reflect, analyze, and decide on how to do things better;
Provide a forum to celebrate success and progress;
Improve team communications and create an opportunity to “clear the air”;
Address issues regularly, eliminating problems sooner rather than later;
Bring everyone up to speed on current challenges and goals;
Empower teams to solve problems, develop solutions, and own their decisions;
Provide an opportunity to reach a consensus on future actions moving forward;
Offer a great opportunity for team building and energizing the team;
The agile retrospective is best known as a tool for agile software development teams (including scrum and extreme programming). However, it is broadly applicable to any project.

STAR Retrospective

One of the many ways to hold an effective retro meeting is to use the STAR approach. Each [Scrum] team may use a board to visualize items that need to be worked on.

Besides that, it is recommended to formally keep track of such records in a structured way.

Tips For Effective Retrospectives

Carefully select participants to provide expert knowledge but also a fresh perspective;
Use technology to involve critical people in different locations rather than miss their contribution;
Minimize groupthink by brainstorming ideas individually and then combining issues to get the overall picture;
Be specific rather than broad when defining ideas;
Use quantitative data where possible to focus on the crux of the issue;
Provide adequate time in the session to rank and prioritize ideas;
Communicate outcomes to stakeholders and regularly update progress on actions;
Add rules and agreements to Agile or Team charter.

Sprint Retrospective Patterns

Review backlog items targeted to Sprint, Sprint Goal, and metrics
Every team member can speak
Use a variety of retro techniques depending on the Sprint result
Each retro ends up with actionable improvements
Each Action Item is assigned to an accountable person
Scrum Team revise Action items from previous retros to make them done
Make the retrospective fun, exciting, and productive

Sprint Retrospective Anti-patterns

#NoRetro
Dispensable buffer
Rushed retrospective
Someone sings
Extensive whining
UNSMART
#NoAccountability
Product Owner non-grata

Scaled Scrum Team Retrospective

For many teams, one has to use an adjusted approach for improvements. Because there are common scaling dysfunctions, every Retrospective should address the following questions:

Has the Team met the Sprint Goal? If not, why not?
Was any work left undone? Did the Team generate technical debt?
Were all artifacts, particularly code, frequently (ideally, continuously) and successfully integrated?
Was the software successfully built, tested, and deployed often enough to prevent the overwhelming accumulation of unresolved dependencies?

When issues are discovered, the representatives need to ask

Why did this happen?
How can the issue be fixed?
How can recurrence be prevented?

The decisions are made by the key people in the team. Usually, they are represented by senior positions and form an Integration Team. After the Retrospective meeting where Integration Team participates, it is important to define the action items to work on within all Scrum teams. The Integration Team has to keep track of such items and may use a table tool to keep working on items of improvement.