KPT-Retrospektive: Retros, die wirklich etwas verändern (Methode, Vorlage, Beispiele)

Die meisten Retrospektiven scheitern auf die gleiche, leise Art. Das Team trifft sich am Ende eines Sprints oder Projekts, teilt ein paar Erfolge, sammelt ein paar Beschwerden und geht mit einem vage produktiven Gefühl auseinander. Zwei Wochen später tauchen dieselben Probleme wieder auf, weil aus dem Gesagten nie eine Veränderung wurde.

KPT ist eine Retrospektiven-Methode, die genau das verhindern soll. Sie ordnet das Gespräch in drei Kategorien: Keep (was gut lief und bleiben soll), Problem (was gestört hat) und Try (was als Nächstes anders laufen soll). Populär geworden in der japanischen Agile-Community, wo sie längst zum Standard gehört, hat die Methode eine Eigenschaft, die sie für jedes Team wertvoll macht: Das Ergebnis des Meetings ist keine Diskussion, sondern eine kurze Liste konkreter Experimente.

Dieser Leitfaden erklärt, was KPT ist, wie das Meeting Schritt für Schritt abläuft, welche Vorlage Sie direkt übernehmen können, an welchen Mustern Retros zur Show verkommen, wie sich KPT von anderen Retro-Formaten unterscheidet und wie Sie das Protokoll automatisieren, damit Ihre Retrospektiven aufeinander aufbauen, statt jedes Mal bei null zu beginnen.

⚠️ Dieser Artikel wurde auf Grundlage öffentlich zugänglicher Informationen und Nutzerfeedbacks mit Stand Juli 2026 unabhängig zusammengestellt.

Inhaltsverzeichnis

1. Was ist eine KPT-Retrospektive?
2. Ablauf einer KPT-Retrospektive: 5 Schritte
3. KPT-Vorlage zum Kopieren
4. KPT-Beispiele aus der Praxis
5. 5 Wege, auf denen KPT-Retros erstarren, und die Gegenmittel
6. KPT im Vergleich mit anderen Retro-Methoden
7. Checkliste für die erste KPT-Retro
8. Retro-Protokolle mit KI automatisieren
9. FAQ
10. Fazit

Was ist eine KPT-Retrospektive?

KPT ist ein Retrospektiven-Format, das alles, was das Team bespricht, in drei Fragen sortiert:

• Keep: Was lief gut und sollte beibehalten werden?
• Problem: Was lief schlecht oder hat uns gebremst?
• Try: Was probieren wir in der nächsten Periode anders?

Verbreitet hat sich die Methode über agile und Scrum-Teams als leichtgewichtige Alternative zur freien Sprint-Retrospektive. Sie funktioniert aber genauso außerhalb der Entwicklung: Vertriebsteams nutzen sie für Monatsrückblicke, Projektteams für Meilenstein-Reviews, Einzelpersonen für die Wochenreflexion.

Der Kern von KPT sind nicht die drei Spalten. Der Kern ist, dass das Format das Gespräch über die Reflexion hinaus in die Handlung zwingt. Keep und Problem sind Rohmaterial; das Arbeitsergebnis ist Try. Eine Retrospektive, die ohne eine kleine, verantwortete Liste von Tries endet, ist nicht fertig, egal wie gut sich die Diskussion angefühlt hat. Wer diese Regel im Kopf behält, vermeidet die meisten der später beschriebenen Fehler.

KPT und die klassische Sprint-Retrospektive

Wenn Ihr Team bereits Sprint-Retrospektiven durchführt, ist KPT kein Ersatzritual, sondern eine schärfere Agenda für dasselbe Meeting.

Die feste Struktur hat einen Zinseszinseffekt: Weil jede Retro dieselbe Ergebnisform produziert, lassen sich Retros über die Zeit vergleichen, und wiederkehrende Probleme werden sichtbar. Genau diese Sichtbarkeit geht in freien Retros verloren.

Ablauf einer KPT-Retrospektive: 5 Schritte

Planen Sie 30 bis 60 Minuten für ein Team von bis zu sechs Personen.

Schritt 1: Rahmen setzen (5 Min.). Benennen Sie Zeitraum und Umfang, etwa „die letzten zwei Wochen, Fokus auf die Release-Arbeit". Wiederholen Sie anschließend laut die Grundregel: Die Retro untersucht die Arbeitsweise des Teams, niemals einzelne Personen. In dem Moment, in dem eine Retro zur Schuldsuche wird, hört sie auf, Informationen zu liefern.

Schritt 2: Keeps sammeln (10 Min.). Alle schreiben ihre Keeps zunächst still auf, auf Haftnotizen oder in ein geteiltes Dokument, danach wird reihum geteilt. Das stille Schreiben vor dem Sprechen ist entscheidend: Beginnt man mit freier Diskussion, verankert die lauteste Stimme den Raum, und die Beobachtungen der Stilleren kommen nie an die Oberfläche.

Schritt 3: Probleme sammeln (15 Min.). Gleiches Vorgehen. Die entscheidende Gewohnheit: Probleme als Fakten formulieren, nicht als Urteile. „Die Kommunikation war schlecht" führt nirgendwohin. „Die Spezifikation wurde nach Implementierungsbeginn zweimal geändert" zeigt direkt auf eine Lösung.

Schritt 4: Tries festlegen (15 Min.). Wählen Sie die zwei bis drei folgenreichsten Probleme aus und entwerfen Sie zu jedem einen Try. Verbieten Sie die Formulierungen „besser aufpassen" und „mehr darauf achten". Ein guter Try ist ein Verhalten, das sich später überprüfen lässt: „Spezifikationsänderungen werden nur als Ticket übernommen, Änderungen mitten im Sprint rutschen in den nächsten Sprint" ist entweder passiert oder nicht.

Schritt 5: Verantwortliche zuordnen und abschließen (5 Min.). Geben Sie jedem Try eine verantwortliche Person und einen Prüfzeitpunkt, und kündigen Sie an, dass die nächste Retro mit der Durchsicht dieser Tries beginnt. Diese Eröffnungsprüfung ist der Motor, der KPT zum Laufen bringt.

KPT-Vorlage zum Kopieren

Fügen Sie das in Ihr geteiltes Dokument oder Whiteboard-Tool ein und starten Sie heute.

# KPT-Retrospektive - [Team/Projekt] - [Datum]
Betrachteter Zeitraum: [TT.MM.JJJJ - TT.MM.JJJJ]
Teilnehmende: [Namen]

## Durchsicht der Tries aus der letzten Retro
- [ ] [Bisheriger Try] - Ergebnis: [hat funktioniert / weiterführen / verwerfen]

## Keep (was gut lief)
- [Was beibehalten werden soll, und warum es funktioniert hat]

## Problem (was gestört hat)
- [Fakten: wann, was, und welche Folgen]

## Try (was wir ändern) - maximal 2-3
- [ ] [Konkreter, überprüfbarer Try] - Verantwortlich: [Name] - Prüfung: [nächste Retro]

## Nächste Retro: [Datum]

Drei Hinweise zur Nutzung:

• Die Durchsicht der letzten Tries steht bewusst ganz oben. Das Format selbst garantiert, dass Retros eine Serie sind und keine Einzeltermine.
• Begrenzen Sie Tries auf zwei bis drei. Zehn Tries bedeuten null Tries. Kleine, verlässliche Veränderungen summieren sich schneller als ehrgeizige Listen, die niemand umsetzt.
• Erzwingen Sie „wann und was" in jedem Problem. Sobald das Team Probleme als Fakten formuliert, springt die Qualität der Tries eine Stufe nach oben.

KPT-Beispiele aus der Praxis

Sprint-Retro eines Entwicklungsteams (Zwei-Wochen-Sprint)

• Keep: Die 15-Minuten-Grenze für das Daily hat sich etabliert, die Vormittage sind ruhiger für konzentrierte Arbeit. Das neue Feld „Kontext" in Review-Anfragen hat die Review-Schleifen verkürzt.
• Problem: Eine Spezifikationsänderung wurde an Tag 3 nur mündlich weitergegeben, zwei Entwickler bauten gegen den alten Stand. Die Staging-Umgebung kollidierte am Tag vor dem Release mit einem anderen Team.
• Try: Spezifikationsänderungen werden erst nach Ticketerstellung umgesetzt (verantwortlich: PM, Prüfung nächste Retro). Staging-Slots werden über den Kalender reserviert (verantwortlich: Infrastruktur, Prüfung nächste Retro).

Monatsretro eines Vertriebsteams

• Keep: Gesprächsnotizen am Tag nach jedem Termin zu verschicken hat die Antwortquote spürbar erhöht. Die Demo in die ersten 15 Minuten zu legen kam bei Interessenten gut an.
• Problem: Verlorene Deals wurden pauschal mit „Preis" begründet, obwohl mehrere in Wahrheit am Zeitpunkt scheiterten. Die Notizqualität schwankte so stark, dass Übergaben Stunden kosteten.
• Try: Verlustgründe werden zur Auswahlliste plus Kommentarzeile (verantwortlich: Sales Ops, Prüfung nächste Retro). Eine gemeinsame Vorlage für Gesprächsnotizen (verantwortlich: Teamleitung, Prüfung nächste Retro).

Beachten Sie: Weil die Probleme in beiden Beispielen als Fakten formuliert wurden, ist jeder Try eine Änderung am System und kein Versprechen, sich mehr anzustrengen.

5 Wege, auf denen KPT-Retros erstarren, und die Gegenmittel

• Tries werden nie umgesetzt. Der häufigste Fehler, und fast immer fehlt schlicht die verantwortliche Person samt Prüfzeitpunkt. Genau dafür existiert der oberste Abschnitt der Vorlage: Jede Retro beginnt mit der Bewertung der letzten Tries.
• Probleme werden zu Beschwerden über Personen. „Alex antwortet zu langsam" ist ein Angriff, kein Problem. Aufgabe der Moderation ist die Übersetzung: „Reviews lagen im Schnitt zwei Tage." Gegenstand ist immer der Prozess, nie die Person.
• Keep wird zum Smalltalk. Keep ist keine Komplimenterunde, sondern der Ort, an dem wiederholenswertes Verhalten identifiziert wird. Ein Satz dazu, warum etwas funktioniert hat, macht aus einem netten Moment einen wiederverwendbaren Baustein.
• Dasselbe Problem taucht zweimal in Folge auf. Das ist ein Signal, dass der letzte Try zu flach war, meist ein „Mehr-Anstrengung-Try". Reagieren Sie, indem Sie für dieses Problem anstrengungsbasierte Tries verbieten und stattdessen Prozess oder Werkzeug ändern.
• Nichts wird festgehalten, also summiert sich nichts. Wer eine Protokollperson bestimmt, nimmt sie aus der Diskussion. Wer ganz auf Notizen verzichtet, kann in der nächsten Retro die letzten Tries nicht prüfen, und jede Retro beginnt bei null. Der KI-Workflow weiter unten löst das, ohne eine teilnehmende Person zu opfern.

KPT im Vergleich mit anderen Retro-Methoden

KPT ist ein starker Standard, aber nicht das einzige Werkzeug im Regal.

Eine praxistaugliche Rotation: KPT als festes Format für die regelmäßige Retro, und für Quartalsrückblicke oder nach Vorfällen eine Timeline-Retro. Wer das Format jede Woche wechselt, belastet das Team vor allem mit dem Neulernen der Regeln.

Checkliste für die erste KPT-Retro

Wenn die Einführung von KPT scheitert, dann meist beim ersten Termin. Wirkt die erste Erfahrung wie „noch ein zähes Meeting mehr", findet ein zweites nicht statt. Prüfen Sie vor der ersten Runde diese acht Punkte:

• Ist der betrachtete Zeitraum höchstens zwei Wochen lang? (Längere Zeiträume verblassen und werden zur Gefühlsrunde.)
• Sind es höchstens sechs Teilnehmende? (Größere Gruppen nach Teams aufteilen.)
• Steht ein geteiltes Dokument oder Whiteboard für die stillen Schreibphasen bereit?
• Ist der Eröffnungssatz eingeplant: „Wir untersuchen den Prozess, nicht Personen"?
• Hat die Moderation das Prinzip „erst schreiben, dann sprechen" verstanden?
• Wurde die Grenze von zwei bis drei Tries kommuniziert?
• Enthält die Vorlage Felder für verantwortliche Person und Prüfzeitpunkt je Try?
• Kann der Termin der nächsten Retro noch vor Ende der ersten in den Kalender?

Noch ein Tipp für die Anfangsphase: Gewichten Sie in den ersten beiden Retros Keep stärker als Problem. Teams ohne Retro-Erfahrung gehen in Verteidigungshaltung, wenn das Meeting mit Problemen beginnt. Vermitteln Sie zuerst die Erfahrung, dass auch Erfolg eine Struktur hat, und die Problemdiskussion wird ab der dritten Retro erstaunlich offen.

Übrigens ist KPT kein reines Teamwerkzeug. Eine Solo-Variante von 15 Minuten am Wochenende, mit eigenen Keeps, Problems und Tries, funktioniert gut. Wer die Methode ein bis zwei Wochen persönlich durchläuft, bevor er sie ins Team trägt, entwickelt das Moderationsgespür aus erster Hand.

Retro-Protokolle mit KI automatisieren

Das hartnäckigste Problem jeder Retro-Praxis ist die Dokumentation. Whiteboard-Fotos sind nicht durchsuchbar. Eine benannte Protokollperson verliert die halbe Diskussion. Und ohne verlässliches Protokoll stirbt still der Schritt „Tries der letzten Retro prüfen", der Motor des ganzen Systems.

Hier setzt ein KI-Meeting-Assistent in Echtzeit an. SuperIntern ist eine botfreie Desktop-App (Mac und Windows), die Meetings direkt über den Geräteton erfasst. Es tritt kein Bot dem Call bei, die App funktioniert also identisch, ob Ihre Retro in Zoom, Google Meet, Microsoft Teams oder Webex stattfindet oder das Team vor einem physischen Whiteboard steht und der Laptop mithört.

Konkret für KPT:

• Bringen Sie AI Canvas Ihr Format einmal bei. Beschreiben Sie es in normaler Sprache: „Das ist eine KPT-Retrospektive. Sortiere die Diskussion in Keep, Problem und Try. Ordne jedem Try eine verantwortliche Person zu und protokolliere die Durchsicht der letzten Tries." Jede folgende Retro füllt sich live in genau dieser Struktur.

• Niemand muss Protokoll führen. Die Notiz wächst während des Meetings, das Abtippen von Haftnotizen nach der Retro entfällt ersatzlos.
• Tries werden im Moment des Aussprechens erfasst. „Dann machen wir Tickets ab nächstem Sprint verpflichtend" landet in Echtzeit als verantworteter Try in der Notiz.
• Die Durchsicht der letzten Tries dauert Sekunden. Öffnen Sie die Notiz der vorigen Retro, und die verantworteten Tries stehen dort. Sie können auch den meetingübergreifenden KI-Chat fragen: „Liste die Tries der letzten drei Retros und alle wiederkehrenden Probleme auf."
• Mehrsprachige Teams bleiben synchron. Echtzeitübersetzung in über 50 Sprachen macht auch die Retro mit dem Standort im Ausland möglich, und die Zusammenfassung erhält jede Person in der eigenen Sprache.

Ein ehrlicher Hinweis: SuperIntern ist eine Desktop-App für Live-Meetings und deren Notizen, kein Haftnotiz-Whiteboard und kein Task-Manager. Viele Teams verbinden es über SuperIntern MCP mit Agenten wie Claude und überführen beschlossene Tries als Tickets nach Linear oder Jira. Es gibt einen kostenlosen Plan, der Test bei der nächsten Retro kostet also nichts.

FAQ

Wofür steht KPT?

Für Keep, Problem, Try. Keep ist, was gut lief und bleiben soll, Problem ist, was gestört hat, und Try ist die konkrete Veränderung für die nächste Periode.

Woher kommt die KPT-Methode?

KPT wurde in der japanischen Agile- und Softwareszene als Standardformat für Sprint-Retrospektiven populär und hat sich von dort in Teams aller Art verbreitet. Die Methode ist mit Formaten wie Start/Stop/Continue verwandt, führt aber direkter zu Experimenten.

Wie oft sollten wir eine KPT-Retrospektive durchführen?

In sprintbasierten Teams einmal pro Sprint (alle ein bis zwei Wochen), in anderen Teams alle zwei Wochen bis monatlich. Wichtiger als die Frequenz ist die Kontinuität: Die nächste Retro muss mit der Durchsicht der letzten Tries beginnen. Eine einzelne lange Retro pro Quartal scheitert meist, weil Erinnerungen verblassen und die Diskussion von Fakten zu Eindrücken abdriftet.

Wie lange sollte das Meeting dauern?

Für bis zu sechs Personen 30 bis 60 Minuten. Wer regelmäßig über eine Stunde braucht, betrachtet einen zu langen Zeitraum, oder die Problemdiskussion rutscht in Ursachenarchäologie ab, statt Tries zu entwerfen.

Funktioniert KPT remote?

Ja, oft sogar besser als vor Ort. Die stillen Schreibphasen übertragen sich natürlich in geteilte Dokumente, und weil das Meeting ohnehin am Rechner stattfindet, können botfreie KI-Notizen Diskussion und Tries festhalten, ohne dass jemand Protokoll führt.

Ist KPT dasselbe wie eine Sprint-Retrospektive?

Die Sprint-Retrospektive ist das Meeting; KPT ist ein Format, um es durchzuführen. Wenn Ihre Retros unstrukturiert wirken oder keine Umsetzung erzeugen, ist die Einführung von KPT im bestehenden Retro-Termin meist die günstigste verfügbare Verbesserung.

Fazit

KPT verdient seine Verbreitung, weil es die kleinstmögliche Struktur ist, die eine Retrospektive trotzdem zu Veränderung zwingt. Die Erfolgsbedingungen sind überschaubar: Probleme als Fakten formulieren, Tries auf zwei bis drei begrenzen und als überprüfbares Verhalten fassen, jedem Try eine verantwortliche Person geben, und jede Retro mit der Bewertung der letzten Tries eröffnen. Wer diese vier Dinge einhält, dessen Retros beginnen, sich zu summieren.

Die Dokumentation, die alles zusammenhält, braucht dafür keine menschliche Protokollperson mehr. Bringen Sie einem botfreien KI-Assistenten Ihr KPT-Format einmal bei, und jede Retro hinterlässt eine strukturierte, durchsuchbare Notiz, während das Team im Meeting seiner eigentlichen Aufgabe nachgeht: entscheiden, was sich ändert.

SuperIntern kostenlos testen : kein Bot im Meeting, Live-Notizen in Ihrem KPT-Format, und jeder Try wird verlässlich in die nächste Retro getragen.