What is the Sprint Retrospective Meeting (event) in Scrum? The Sprint Retrospective is an opportunity for the Scrum Team to inspect itself and formulate a plan for changes to be performed during the next Sprint. The Sprint Retrospective occurs after the Sprint Review and before the next Sprint Planning.
The Sprint Review event is just over. Following is the latest Scrum event for Sprint called Sprint Retrospective.
Now is the time to balance a lot of things.
- Was The Development Team Successful?
- Was the entire Scrum team successful?
- What did you do well and what you didn't do well?
- You have to ask yourself why.
- What can you change?
Sprint Retrospective is a Scrum event at the end of each sprint and before the new Scrum sprint begins.
The event should help the Scrum team improve their practices, identify problems more efficiently, and deal with them more adequately.
Each Scrum team, whether beginner or advanced, must perform Sprint Retrospective. This event is a significant part of the Scrum framework. A Sprint Retrospective is a meeting at which the team discuss the recently completed sprint and make an action plan for the upcoming Sprint.
The Scrum Master role is a leading figure during this event. The Scrum Master role provokes the entire Scrum team and teaches everyone the benefits of the event. The Scrum Master role engages and motivates everyone's participation and again, aims for transparency and initiative. If there are precisely defined lessons learned for the entire team, now is an excellent time to be presented, communicated, and explained to all Scrum team members.
The Sprint Retrospective Event aims to inspect and adapt just like most Scrum ideas. This time, inspection and adaptation are not about the product, but the team, the attitude, and productivity.
The Sprint Retrospective Event (meeting) questions
The Sprint Retrospective Event addresses the following fundamental questions:
- What went well during the Sprint?
- What went wrong during the Sprint?
- What can be done differently and better in the next Sprint?
The Scrum Team needs to be able to evaluate everything in its Sprint very thoroughly. If a process has been an obstacle, the team may decide to suspend that problematic process. If any change is considered necessary, it should be carefully analyzed, planned, and activated.
By conducting regular retrospectives after the end of each sprint, it is assumed that the Scrum team will become better, the processes more useful and flexible, and the obstacles less.
Continuous improvement also includes continuous removal of barriers to the team. By constructively discussing the situation at the end of the sprint, the Scrum team can identify obstacles and focus on their subsequent elimination and identify valuable remedial measures.
An obstacle can be called anything that slows the team down or prevents the team from providing business value. It is the responsibility of the Scrum Master to identify, track, and remove obstacles, or to assist the team in removing the obstacles themselves.
Remember the Daily Scrum event (meeting), which is the perfect time to share problems. If problems are recorded in advance during the Sprint Retrospective event, all documented issues can be discussed in detail.
By discussing the obstacles as soon as possible after their occurrence, the team's chance of dealing with them increases.
It is important to discuss the source of the problems, not just the issues themselves. The depth and cause of a problem are where improvement efforts must focus.
Who helps solve problems of all kinds?
The Scrum team should try to fix their problems on their own. The team must be mature, responsible, self-initiated, and self-organizing.
The development team is self-driven.
Scrum Master and Product Owner roles also do their best to solve problems.
However, if the Scrum team fails to cope with a problem, it must seek help and assistance beyond its configuration.
Scrum looks like a closed loop, a cycle, and a process, but it should not be considered that way. Assistance can come from both the client and the organization you work for.
In addition to watching, recording, and eliminating problems and obstacles, the Scrum Master role is also responsible for encouraging others to do the same. The Scrum team does not have to wait for the Scrum Master role to resolve all issues. In addition to helping, the Scrum Master role should motivate the team and support it in all actions.
It is good practice to keep a list of team problems.
Just as the product has a list of all the work needed, the whole Scrum team can have a list of their problems.
Prioritize the issues by importance, power of influence, frequency of manifestation, or other defined parameters. Statuses can be assigned to any problem. Which problem is under consideration, which problem is pending and not started, which issue is closed and resolved. You can also assign yourself "responsible" for any challenge. Each team member should be willing to help themselves instead of waiting for the Scrum Master role to appoint a responder.
An indicative time can also be set to solve each problem. You can also create a "vote" type for each problem if this will help with prioritization. Each participant can state their vote on an issue. To make the process more flexible, one can use a technique in which each participant has the right to rate value from 0 to 3 for each problem.
Who are the participants in the Sprint Retrospective event?
The entire Development Team and Scrum Master role are required.
The Product Owner role is optional. If the team needs their Product Owner, this role can be invited to discuss product area issues. Although Scrum rules do not require the participation of the Product Owner, his/her attendance is recommended. Surely there will always be something to discuss on the Product Backlog, the product itself, business needs, issues, the direction of action.
The presence of the entire Scrum team also affects the union and relationships between the participants of the whole Scrum team.
Negative presence of the Product Owner role during the Sprint Retrospective event
The very presence of a Product Owner role can be a hindrance and a problem for the Development Team and make some (or all) of the Development Team members uncomfortable.
The Scrum Master role should remove this obstacle for the team by politely explaining this problem to the Product Owner role.
For the future, this issue should be discussed with the Product Owner role and resolved.
Negative presence of the Scrum Master role during the Sprint Retrospective event
The most unpleasant situation for the Development Team is the Scrum Master, which makes the team feel uncomfortable, and the Scrum Master itself is an obstacle.
The Scrum Master role would not be appropriate to remove itself from the team as an obstacle, but should self-monitor, self-inspect, and seek regular feedback from all members of the Development Team. The Scrum Master role should work on their personality, mood, behavior, and professionalism when such a need for improvement is identified.
Sprint Retrospective event and business stakeholders
Business stakeholders rarely attend the Sprint Retrospective event. In theory, their presence, according to Scrum principles, is not allowed.
However, a possible reason for business stakeholders to participate in the Sprint Retrospective event may be, for example, the strengthening of the relationship between the Scrum team and the organization (or client). All parties can feel the problems of others and understand the specific details.
Occasionally, inviting business people can be practiced if the entire Scrum team believes that this approach would be useful.
Sprint Retrospective event and Scrum Master role
In summary, the Scrum Master role has the following objectives related to the Sprint Retrospective event:
- Take care of the productive, open, honest, and appropriate environment and atmosphere of the event.
- Provokes the most basic questions like "What did we do well?", "What didn't we do well?" and "What can we improve for the next sprint?" and seek their answers.
- Records all opinions and comments.
- Recalls information and comments from a previous Sprint to be considered and eventually discussed.
- Encourages the equal participation and activity of all present.
- Keeps records of problems.
- Provokes participants to solve problems.
- Manages archives from previous meetings.
- Indicates important points from the past if there is a need for new discussion and if the problems are still unresolved.
- Focuses participants' attention to the goals of the event and aims for effectiveness.
- Keeps track of the meeting time limit.
- Provokes new thinking and ideas as he/she tries to develop the team in the direction of solving its problems.
- Directs attention to the most productive ideas and goals of the team.
The notes on what is done well, what is not done well, and what needs to be improved can be stored in a tabular form as follows:
|What have we done well?||What have we not done well?||What can we improve?|
Retrospection discusses what happened during the Sprint. Everything negative and positive is indicated and described. The idea of how improvements can be implemented is also described.
Common problems and obstacles can be different and are recorded not only during the Sprint Retrospective event. The Scrum Master role can keep an archive based on the topics discussed during the Daily Scrum event.
Duration of the Sprint Retrospective Event
For a one month sprint, the maximum event time is 3 hours.
For a two-week sprint, the event is an hour and a half, respectively.