Bezpośrednio po zakończeniu Przeglądu Sprintu cały Zespół Scrum odbywa już we własnym gronie Retrospekcję Sprintu (ang. Sprint Retrospective). Jest to spotkanie, podczas którego analizuje się sposób pracy Zespołu podczas kończącego się Sprintu. Celem jest zastanowienie się w jaki sposób pracę tą można usprawnić w przyszłości. Efektem spotkania jest lista konkretnych usprawnień (ang. actionable improvements), które Zespół będzie wprowadzi w życie w następnym Sprincie. Oczywiście, jest to jednocześnie prognoza odnośnie tego, czy usprawnienia te faktycznie są możliwe do wprowadzenia i czy ich realizacja przyniesie spodziewane korzyści.

Retrospekcja Sprintu trwa maksymalnie 3 godziny dla miesięcznych sprintów, zazwyczaj jest krótsza przy krótszych Sprintach (dobry wskaźnik to 45 min na tydzień Sprintu). Scrum nie określa sposobu prowadzenia Retrospekcji, która jest praktyką samą w sobie. Wymagane natomiast jest, aby Zespół Srum co Sprint analizował swoją pracę i szukał usprawnień. Dzięki temu można powiedzieć, że sam Zespół – co Sprint lepszy – jest drugim, po Przyroście, produktem każdego Sprintu.

Określenie „konkretne usprawnienia” oznacza, że oczekujemy nie ogólnych życzeń ale konkretnych działań – i to takich, których wprowadzenie jest realne w czasie jednego Sprintu. Tak więc zamiast deklarować, że np. „chcemy pisać więcej testów” (życzenie), Zespół powinien raczej zdecydować: „w kolejnym Sprincie dla jednego z wymagań zaimplementujemy komplet testów” (konkretne działanie, realistycznie realizowalne w jednym Sprincie).

Podejście to wynika ze słusznej obserwacji, że wszelkie usprawnienia są osiągane nie metodą przełomów i „wielkich postanowień” lecz systematycznych, małych kroków ku lepszemu. Konieczność realizowania Retrospekcji co Sprint ma zapewnić, że Zespół będzie owe kroki co Sprint podejmował.

W Retrospekcji Sprintu uczestniczy zarówno Product Owner, jak i Scrum Master oraz wszyscy Developerzy, ponieważ żadna z tych osób nie ma w ramach tego zdarzenia specyficznych obowiązków. Wszyscy poszukują sposobu, by pracować lepiej, a choć przychodzą z różną pespektywą odpowiedzialności, jakie na siebie wzięli, wciąż są jednym Zespołem i zmiany wprowadzać muszą wspólnie. Nie dałoby się też np. usprawnić współpracy między Developerami i Product Ownerem, gdyby tego ostatniego na Retrospekcji zabrakło.

Częstym błędem jest traktowanie Retrospekcji jako narzędzia do „naprawiania tego, co źle działa”. Spotkanie służy przede wszystkim szukanie sposobów na efektywniejsze działanie w kolejnym Sprincie. A zawsze da się zrobić coś lepiej, niekoniecznie dlatego, że robiło się to do tej pory źle. Pojawiają się nowe możliwości, można nauczyć się jakiejś przydatnej praktyki, eksperymentować z różnymi sposobami organizacji pracy itd.

Praca związana z realizacją usprawnień zidentyfikowanych w czasie Retrospekcji Sprintu powinna znaleźć odzwierciedlenie w Backlogu Sprintu kolejnej iteracji — nie powinna natomiast być umieszczana w Backlogu Produktu. Backlog ten opisuje przecież zmiany, jakich dokonać należy w produkcie (a nie w Zespole), poza tym w ten sposób to Product Owner decydowałby o tym kiedy i czy w ogóle usprawnienia te zostaną zrealizowane.

Za realizację usprawnień odpowiada cały Zespół Scrum, a nie wyłącznie Developerzy.

W trakcie Retrospekcji mogą być dyskutowane kwestie związane z produktem, ale nie tyle z jego wartością i dalszymi planami rozwoju (bo to odbywa się na Przeglądzie Sprintu), co ze sposobem, jak ma być rozwijany. Z takich dyskusji wynikają często zmiany Definicji Ukończenia, gdy Zespół dokonuje inspekcji bieżącej Definicji i postanawia ją dostosować tak, by lepiej odzwierciedlała to, co trzeba zrobić, by powstał Przyrost.