Sprint Retrospective

… you are reaching the end of a Sprint, and are getting ready for the next one. Naturally, no matter how well it went, you would like to improve.

✥       ✥       ✥ 

Over time, without explicit attention, processes and discipline tend to decay. People get sloppy. Making isolated process changes without due focus feeds entropy, but without periodic change the team misses opportunities to increase value.

You want to continuously improve. The Daily Scrum gives the team a chance to examine itself and improve the product direction on a daily basis. However, it is not a forum appropriate to re-chart the process for several reasons.

First of all there is daily variation in performance — making adjustments that react to normal variations in the process is pointless. A single day (from one Daily Scrum to the next) is often too short to see whether a change really results in the desired improvement and changing processes in the middle of the Sprint is disruptive at best. Second, the focus of the Daily Scrum is inspection and adaptation to achieve the Sprint Goal. Thus the horizon is very short-term, and the focus of the Development Team is to complete their work rather than on systematic team issues. A third reason is that in the heat of battle (in the middle of a Sprint), you are likely to get only one or two perspectives on a problem, rather than a full appreciation of most contributing factors. Actions taken based on incomplete information may well be inappropriate.

The Sprint Review is used to examine the product with the stakeholders. This event is not the place to analyze the problem(s) and to propose improvements, but to rather focus on the product. The Development Team and the Product Owner should take ownership of the problem(s) as a Self-Organizing Team and determine how to deal with it outside the Sprint Review, and without the stakeholders.

Since Sprints come one after another, there is a tendency to rush from one Sprint right into the next, with little or no thought about how the work was done. This leads to doing the same things over and over; making the same mistakes.

Having made several improvements over the last Sprints the Scrum Team might become convinced that they are doing a good job and that new improvements cannot be found (“this is just the way how we work!”). The added value of improving seems to decline and therefore it is viewed as a waste of time (“we are already very busy doing real work!”).

Team members are put in a vulnerable position when the team examines itself. They might feel embarrassed, threatened or incompetent. This can lead to defensive behavior in which they can deny their own responsibility and externalize the problem. [1]


At the end of each Sprint have an event where the Scrum Team can assess how it did its work during the Sprint.

Hold a Sprint Retrospective at the end of the Sprint. This is a natural time for reflection. Examination of work that is brought to completion allows a full system perspective (where the system is the team and its processes). Taking stock of how one is doing while in the middle of a process gives only a partial picture, and from a very limited perspective. So we align retrospectives with completion of work — at Sprint boundaries. In addition, the challenges and triumphs of the Sprint are still fresh in everyone’s minds.

The team proposes process changes in the interest of achieving Greatest Value. A process change can relate to either people, relationships, process, or tools.

✥       ✥       ✥ 

Scrum has its roots in the Toyota Production System (TPS), which has process improvement at its heart. In the TPS manual we find the instruction, “Checking is about hansei.” Hansei is a deep form of personal or collective regret for having failed. A good Scrum Team does hansei over its failures, and then redirects the energy of regret for the failure into positive energy for fixing the problem; see Scrumming the Scrum. The Sprint Retrospective is therefore also a time of healing and renewal for the team. Taiichi Ohno is considered the founder of the TPS. A famous quote commonly attributed to him is:

No one has more trouble, than the person who claims to have no trouble. (Having no problems is the biggest problem of all.)

Focus on developing a culture where the Sprint Retrospective is carried out as an essential part of every Sprint. Build it into the regular cadence of the team. Avoid the temptation to skip it because you feel you need the time to complete the last of the Sprint’s work. This would reinforce a cultural belief that Retrospectives are not really important.

Time-box the meeting. Allow enough time to explore issues in some depth, but don’t make it so long that people get bored. Scrum recommends a three-hour meeting for a one month Sprint. The meeting is usually shorter when the Sprint is shorter.

Normally, the entire Scrum Team should attend, including the Product Owner. On rare occasions, if the Development Team feels that the Product Owner dominates the conversation or otherwise suppresses frank and open discussion, they might ask the Product Owner not to attend. Note that this is likely a sign of larger problems, though. Because Scrum is a framework that helps remove problems to achieve ever greater value, and since the Product Owner is at the heart of the value proposition, trusted participation of the Product Owner in these meetings is key to long-term success beyond any superficial measure.

One principle of the Agile Manifesto [2] is to have regular Retrospectives:

At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly.

Retrospectives, especially regularly scheduled ones, can easily become superficial meetings where no substantive issues are explored. To deal with this use known effective methods of Retrospectives, such as cataloged in [3]. For example, one method is to identify things that went well, ongoing problems, and specific things to do [4], [5]. Consider varying the method from time to time. Base the discussion on empirical insight. In particular, examine such concrete indicators as percent of the Sprint Backlog completed and team velocity. Furthermore, identify specific process changes to be made during the next Sprint.

The changes to be made should be ordered by priority in the Impediment List. The pattern, One Step at a Time recommends that the team make a single change at a time, so they can understand how each change impacts the team; see also Scrumming the Scrum. The pattern Happiness Metric suggests that the most important change is dictated by what single change would improve the happiness of the team the most. Be sure also that you can measure the implementation of the change, as well as its cost, benefits, and disadvantages (see Testable Improvements).

Consistent use of a Sprint Retrospective does not guarantee process improvement or even process stability, and though it’s not sufficient to just do Retrospectives, it’s probably necessary to regularly bring the kaizen mind to a focus. Done right, Sprint Retrospectives encourage the team and give them pride in being able to improve over time; see Product Pride.

Retrospectives easily degenerate into whining sessions. In order to combat this problem go into the Retrospective following Norm Kerth’s prime directive: “Regardless of what we discover, we understand and truly believe that everyone did the best job they could, given what they knew at the time, their skills and abilities, the resources available, and the situation at hand.” [5]. This requires a Community of Trust. Also make the team aware of what they themselves can change and what they cannot change on short term, or maybe not at all [6]. Furthermore, identify both good things (“nuggets”) and problems. Don’t just look at the bad. Some of the good things may be worth writing down. For example, newly learned techniques that help Done should be added to a written Definition of Done. Whining can also indicate deeper issues.

Note that Retrospectives of just two or three hours are typically insufficient to explore deep issues. Sprint Retrospectives are therefore somewhat of a compromise between depth of discussion and length of the meeting. A problem found during the Sprint Retrospective might owe to deeper, complex relationships that the group cannot properly surface and explore in just three hours. An experience report from Jeff Sutherland based on a communication he had with the Investment Group notes the following:

Impediments are like mosquitos. You swat one and 25 come back. So, you need to get the root-cause. What you have to do is drain the swamp to get those mosquitos to stop coming.

In order to “drain the swamp” you can consider working at the level of double or even triple loop learning as described by Swieringa and Wierdsma in 1992 [7]. In short: single loop learning is about changing the rules and double loop learning changes the underlying structure. Triple loop learning deals with the essential principles and values on which the organization is founded. Norm Kerth suggests that it requires three days to explore the deep structural issues in an organization, and he has proposed a framework for three-day, off-site Retrospectives that drive at this level of improvement. [5] The extensive Retrospective of Kerth is more suitable for dealing with deep vulnerabilities of the team because more time is invested in creating trust in the team than in the relatively short Sprint Retrospectives.

[1] Chris Argyris. “Teaching smart people how to learn.” Reflections 4(2), 1991, https://www.ncsu.edu/park_scholarships/pdf/chris_argyris_learning.pdf (accessed 2 November 2017).

[2] —. Manifesto for Agile Software Development. Agilemanifesto.org, http://agilemanifesto.org/principles.html, 2001, accessed 23 January 2017.

[3] Esther Derby and Diana Larsen. Agile Retrospectives. Raleigh, NC: Pragmatic Bookshelf, 2006.

[4] Alistair Cockburn. Agile Software Development, 2nd ed. Reading, MA: Addison-Wesley, Oct. 2006.

[5] Norm Kerth. “How long should a retrospective be?” In Project Retrospectives: A Handbook for Team Reviews. New York: Dorset House Publishing, 2001, ff. 53.

[6] Stephen R. Covey. The Seven Habits of Highly Effective People Simon & Schuster, 1992.

[7] Joop Swieringa and Andra Wierdsma. Becoming a Learning Organization. Reading, MA: Addison Wesley, 1992, pp. 37-42.

Picture from: PresenterMedia.com.