Sprint Retrospective

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.

1. The Sprint Retrospective Event (meeting) questions
2. Obstacles
3. Who helps solve problems of all kinds?
4. Who are the participants in the Sprint Retrospective event?
5. Negative presence of the Product Owner role during the Sprint Retrospective event
6. Negative presence of the Scrum Master role during the Sprint Retrospective event
7. Sprint Retrospective event and business stakeholders
8. Sprint Retrospective event and Scrum Master role
9. Duration of the Sprint Retrospective Event

When the Sprint Review ends, the last Scrum event called Sprint Retrospective follows.

This is when a lot of things can be balanced.

• Was The Development Team Successful?
• Was the entire Scrum team successful?
• What was done well and what wasn’t?
• Why did positive and negative events occur?
• What could change?

Sprint Retrospective is a Scrum event that happens at the end of each Sprint and before another one 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 discusses the recently completed Sprint and makes an action plan for the upcoming one.

The Scrum Master role is a leading figure during this event. It motivates the entire Scrum team and teaches everyone the benefits of the event. It makes sure that everyone is engaged and participates and again, aims for transparency and initiative. If the entire Scrum team has to learn particular lessons, this event is the perfect time for them to be presented and taught.

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 it. If any change is considered necessary, it should be carefully analyzed, planned, and set in motion.

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.

Obstacles

Continuous improvement includes removal of obstacles as well as 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.

The Daily Scrum event (meeting) is the perfect time to share problems. If they are recorded in advance, all documented issues can be discussed in detail later, which would make it easier for the Scrum Master to work on them.

The faster the teams discuss the occurring problems, the easier it is to sort them out.

It is important to find the source of the problem instead of just discussing the obvious issues. The improvement methods depend on the severity and the cause of the problem.

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 looking for 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.

It’s a good practice for the team to keep a list of their problems, just like the product has one for all the work that needs to be done.

Prioritize the issues by importance, power of influence, frequency of manifestation, or other defined parameters. Statuses can be assigned to any problem. Some problems might be under consideration, some pending, and others might be 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" 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 the problem from 0 to 3.

Who are the participants in the Sprint Retrospective event?

The entire Development Team and Scrum Master role are required to participate.

The Product Owner role is optional. If the team needs their Product Owner, this role can be invited to discuss product 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 concerning the Product Backlog, the product itself, business needs, issues, the direction of actions.

The presence of the entire Scrum team also affects the union and relationships between all participants.

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 members uncomfortable.

The Scrum Master role should deal with 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 will be if the Scrum Master makes the Development team feel uncomfortable, which makes him or her an obstacle.

As this is a problem that can’t simply be removed, the Scrum Master should self-monitor, self-inspect, and seek regular feedback from all members of the Development Team. They 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 get acquainted with the problems of others and understand the specific details.

Occasionally, inviting stakeholders can be practiced if the entire Scrum team believes that this approach would be useful.

Sprint Retrospective event and Scrum Master role

To summarize, the Scrum Master role has the following objectives related to the Sprint Retrospective event:

• Takes 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’s 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:

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.

Problems and obstacles can vary 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.

The following issues related to chapter "Sprint Retrospective" are included in the certification exam. The sequence of questions is presented in the table.
The data is current as of December 11, 2024, 12:38 pm