Get certified - Transform your world of work today


Introspecting Scrum Retrospectives

21 January 2014

Prabhakar Gumma

Retrospection, one of the Scrum ceremonies, is a powerful mechanism allowing teams to introspect and share constructive feedback for future improvements. Team members tend to be excited about participating and providing their feedback. However, the excitement level may gradually decrease with time, and then this ceremony takes the shape of a regular meeting. Such trends are not desirable for a healthy Scrum practice, so it is important for us to examine how they come about.

While retrospection gives team members a fair chance to express their views and give feedback to the whole team, the effectiveness of retrospection ceremonies depends on the way action items are tracked to closure. Here are some common observations I have made, based on my experience with teams performing Scrum retrospectives.

Practice 1: Plan for retrospection
Current practice: The ScrumMaster sends meeting invitations to all team members at the end of a sprint, and Scrum "chickens" are also informed, though they do not participate. During the meeting, the ScrumMaster sets the context by asking team members to express their views in three categories about the past iteration: what went well (something to continue), what needs to stop (something to discontinue), and what could be improved upon (something new to start).

  • Publish previous retrospective action items in a tracker, and detail the improvements identified in the previous retrospective along with their current state of implementation.
  • Identify a backlog for the session. I would recommend that agenda items in a retrospective should be sevenfold, as depicted in Figure 1 below. Each item is detailed in the recommendation sections.
  • A retrospective comes at the end of the sprint or release. It's a forum for the free flow of ideas, and let it be fun-filled. Have a team-building exercise or party toward the end of it. These may act as motivators for the team.
  • Use post-its as much as possible, rather than asking team members to express their views verbally. This allows members to express their views in an anonymous way. However, in cases where there is a distributed team, use of Web-based tools is favored.
Figure 1: Retrospection Kanban

Practice 2: Participation
Current practice: I had seen very few instances when team members do not join the retrospectives. However, attending and participating are two different things. Though team members join the meeting, they may not be comfortable expressing their views. Scrum teams are flat, built on the servant-leadership philosophy, but often the organizational structure beyond the team is not, and thus team members may be cautious about expressing ideas that could go out as action items.

  • Once the team is in the retrospective session, perform a safety-check exercise. This is to ensure that team members are comfortable being honest in the session. Team members are asked to gauge their participation level on a scale of 1 to 5 (1 being uncomfortable and 5 being candid in their opinions). Have them place their rating on post-its on a wall so they can remain as anonymous as possible. Next, based on this feedback, make a decision about whether to continue with the retrospective. If feedback from participants averages lower than a 3, the ScrumMaster should probably instead have one-on-one discussions with team members to understand the reason for their feedback and to set actions to improve the team's overall safety score.
  • Set rules for participation. Allow team members to express their view in writing, on post-its, for at least 15 to 20 minutes. One view per post-it per team member ensures an appropriate grouping for the second part of the retrospection.
  • In many scenarios where the team is from a service organization, or vendors and the product owner are the customers, it is appropriate not to have the product owner present, since this adds another dimension, that of the customer-vendor relationship, to the meeting. However, the product owner's views should be identified separately.

Practice 3: Identify process gaps
Current practice: Teams identify process gaps based on their experience. However, in some instances the gaps are so wide that they seem to be identified only for the team's short-term benefit, not as a standard process across the organization. Identified improvements tend to be so large in number that the team loses track of discussing key items. Also, teams tend to put the root cause of any process gap on a role or an individual indirectly. In some instances, due to a backlog of many identified gaps, a root-cause analysis is done in only a limited way.

  • Apply the 80/20 rule: 80 percent of problems are due to 20 percent of causes. Logically group the feedback into meaningful categories, such as configuration management, estimation, infrastructure, etc. Based on the feedback, such logical groups can be formed, then map the team's feedback to each of these groups. However, such groups should in no way restrict the free flow of ideas and team viewpoints. It is a good practice to prioritize the improvements and stop-items as a second step in the retrospective. Prioritization ensures that the team is focused on the key items impacting them.
  • There is always a debate about whether deep-dive sessions on the identified improvements should be part of the retrospective or should be considered separately. This is where timeboxing of retrospective activities is required to ensure that the ceremony is completed within the allotted time. I believe that some time should always be slotted within retrospectives for brainstorming the top three improvement areas, although a deep-dive session should be planned as an action item.
  • Identified improvements should always be cross-verified with the existing organizational processes in that area. In some instances there might be existing process improvement initiatives identified for similar improvements within the organization, and thus the team only needs to align itself to the existing objective.

Practice 4: Identify owners
Current practice: Once process gaps and improvements are identified, a key task is to identify the owners for closing the gaps and tracking them to closure. Often, most of the improvements are identified with the ScrumMaster, and he or she is the primary responsible person to manage them. In some cases where infrastructure and human resources are the relevant areas, management is made responsible.

  • Owners should be identified based on their current roles and the impact they have on the identified improvement.
  • It is not recommended to make the ScrumMaster the owner for all action items coming out of the retrospective. However, the ScrumMaster is responsible for communicating ownership to a stakeholder who was not part of the retrospective meeting but owns an action item.
  • Brainstorming sessions should be planned by action-item owners to address the identified improvements and the actions to be stopped, and plans should be identified for implementation. Feedback sessions should be planned involving other stakeholders, based on the solutions identified.

Practice 5: Track actions
Current practice: This is one area where, in my experience, most Scrum retrospectives fail, because of the lack of a mechanism to track action items to closure. Very few actions that address issues other than the behavioral patterns of Scrum teams, such as ensuring daily stand-ups and limiting meeting times, are adopted. The team as a whole needs to adopt such behavioral patterns, thus they tend to start implementing corrections immediately. However, action items assigned to management or any other stakeholder outside the Scrum team are rarely implemented.

  • Identified actions need assigned owners. Avoid multiple owners for one action item.
  • Create a retrospective action-item tracker and place it adjacent to team's wall boards. This will ensure that all stakeholders have visibility into the action, the tracker, and the current status of improvements.
  • Adopt a daily stand-up mechanism among action-item owners to ensure that actions are being worked on and that any impediments are being tracked to closure.
The "Big Idea"
Retrospectives should continue to be a team exercise with the intent of continuous improvement. Although most Scrum teams have adopted this ceremony as a practice, its effectiveness can be measured only by the team's satisfaction in such ceremonies. I recommend that the team conduct "smiley-meter" surveys toward the end of retrospectives to understand how the team feels about the ceremony. Again using post-its, have team members rate their level of satisfaction (0 being lowest and 5 being highest) with the retrospective.
Figure 2: Smiley-meter survey

Opinions represent those of the author and not of Scrum Alliance. The sharing of member-contributed content on this site does not imply endorsement of specific Scrum methods or practices beyond those taught by Scrum Alliance Certified Trainers and Coaches.

Article Rating

Current rating: 4 (4 ratings)


Be the first to add a comment...

You must Login or Signup to comment.

The community welcomes feedback that is constructive and supportive, in the spirit of better understanding and implementation of Scrum.


Newsletter Sign-Up