Article
Introduction
The retrospective is the keystone ceremony of the Scrum framework, the moment where a team pauses to reflect on its process and commit to improvement. The literature on Agile methodology describes the retrospective as a continuous improvement engine, a feedback loop that refines team performance over successive sprints. This paper investigates whether that description has any empirical basis.
We were motivated by a pattern observed informally across multiple consulting engagements: the retrospective produces action items, the action items are assigned to individuals, and in the following retrospective, the same items appear again, assigned to the same individuals, accompanied by the same expressions of good intent. We wished to determine whether this pattern was anecdotal or systematic.
It is systematic.
Methodology
We embedded observers in 9 organizations ranging from 12 to 340 employees, all self-describing as practitioners of Agile or Scrum methodologies. Observers attended all retrospectives for 12 months and photographed or transcribed all action items generated. We followed each action item through subsequent sprints, coding its status at the start of each following retrospective as: completed, partially completed, abandoned (explicitly dropped), or regenerated (re-appearing on the new action item list, with or without acknowledgment of prior appearance).
Regeneration was coded without regard to wording; items with substantively identical intent were counted as the same item even when rephrased. We employed two coders and achieved κ = 0.87 on regeneration coding.
Results
Of 312 action items tracked, 278 (89.1%) were never completed during the study period. An additional 27 (8.7%) achieved partial completion states that, upon inspection, consisted primarily of a Jira ticket being created and assigned. The remaining 7 (2.2%) were completed but subsequently reversed: in six cases because the change was vetoed by management, and in one case because the team forgot they had implemented it.
The regeneration rate was 94.6% (295 of 312 items), with a mean of 3.2 regenerations per item over the 12-month study period. One item — “improve communication between frontend and backend teams” — was generated independently in all 52 retrospectives across all 9 organizations, appearing to be a universal constant of software development rather than an organizational specific.
Discussion
Our results are consistent with the hypothesis that the sprint retrospective functions primarily as a structured grievance ceremony rather than a process improvement mechanism. The generation of action items provides emotional resolution — problems have been named, ownership has been assigned, improvement has been scheduled — without requiring that any of these things actually occur.
We note that organizations in our sample reported high satisfaction with their retrospective process. Satisfaction, it appears, is generated by the ceremony itself rather than by its outcomes.
References
- Scrum, B. D. (2020). “The Scrum Guide.” Scrum.org, pp. 1-13. (We have read this. It does not mention what happens when nothing improves.)
- Action, I., & Item, A. (2023). “Lifecycle of the Forgotten Task.” Journal of Backlog Management, 6(3), pp. 44-58.
- Velocity, V. (2024). “What Sprint Velocity Measures Besides Sprint Velocity.” Agile Suffering Quarterly, 11(2), pp. 1-8.
- Hypothesis, N., & Retrograde, R. (2025). “Retrospective Action Items from This Paper’s Review Process.” I3E TOIL, 1(1), pp. 22-22.