Die OKR-Methode und Scrum tauchen in vielen Startups gleichzeitig auf – und sorgen dann für Verwirrung. Brauchst du beides? Entsteht doppelte Planungsarbeit? Oder kannst du dir eines der beiden Frameworks sparen? Die kurze Antwort: Beide lösen unterschiedliche Probleme. OKR legt fest, welche Ergebnisse ein Unternehmen in einem Quartal erreichen will. Scrum organisiert, wie ein Team Woche für Woche liefert.
In diesem Artikel erfährst du, wie die beiden Ansätze funktionieren, wo sie sich überschneiden und wie du sie so verbindest, dass keine Doppelstrukturen entstehen. Dazu gibt es ein durchgespieltes Praxisbeispiel aus einem jungen SaaS-Unternehmen, typische Fehler und eine Antwort auf die Frage, ab welcher Teamgröße sich das Ganze lohnt.
Was ist die OKR-Methode?
OKR steht für Objectives and Key Results, also Ziele und Schlüsselergebnisse. Ein Objective beschreibt qualitativ, was du erreichen willst – zum Beispiel „Neue Kundinnen finden schneller zum ersten Erfolgserlebnis“. Die Key Results machen messbar, woran du erkennst, dass das Ziel erreicht ist, etwa „Anteil aktivierter Testaccounts steigt von 25 auf 40 Prozent“.
Entwickelt hat das Prinzip Andy Grove bei Intel, aufbauend auf Peter Druckers „Management by Objectives“. John Doerr brachte es 1999 zu Google, von wo aus es sich in der Tech-Branche verbreitete. Üblich ist ein Rhythmus von einem Quartal, pro Objective drei bis fünf Key Results. Viele Teams formulieren bewusst ambitionierte Ziele und bewerten am Ende jedes Key Result auf einer Skala von 0,0 bis 1,0.
Die OKR-Methode einfach erklärt
Vereinfacht gesagt beantwortet die OKR-Methode drei Fragen:
- Wohin wollen wir? Das Objective gibt Richtung und Motivation.
- Woran messen wir den Fortschritt? Key Results sind Ergebnisse, keine Aufgaben.
- Wie oft schauen wir hin? Regelmäßige Check-ins, meist wöchentlich oder alle zwei Wochen, plus eine Auswertung am Quartalsende.
Wichtig ist der Unterschied zwischen Ergebnis und Aktivität: „Onboarding-Video produzieren“ ist eine Aufgabe, „Abbruchquote im Onboarding sinkt um ein Drittel“ ist ein Key Result. Ausführlicher erklärt das unser Grundlagenartikel OKR verstehen: So funktioniert die Zielsetzung in Unternehmen.
Scrum im Überblick
Scrum ist ein leichtgewichtiges Framework für die Entwicklung komplexer Produkte. Grundlage ist der Scrum Guide von Ken Schwaber und Jeff Sutherland, dessen aktuelle Fassung aus dem Jahr 2020 stammt. Sie kennt drei Verantwortlichkeiten: Product Owner, Scrum Master und Developers. Das frühere „Entwicklungsteam“ als eigene Rolle gibt es in dieser Fassung nicht mehr.
Gearbeitet wird in Sprints von maximal einem Monat, in der Praxis meist zwei Wochen. Jeder Sprint enthält feste Events: Sprint Planning, Daily Scrum (15 Minuten), Sprint Review und Sprint Retrospective. Dazu kommen drei Artefakte mit jeweils einer Verpflichtung:
| Artefakt | Verpflichtung | Zweck |
|---|---|---|
| Product Backlog | Product Goal | Langfristiges Ziel des Produkts |
| Sprint Backlog | Sprint Goal | Ziel des aktuellen Sprints |
| Increment | Definition of Done | Qualitätsstandard für fertige Arbeit |
Wer tiefer in die Rolle des Scrum Masters in kleinen Teams einsteigen will, findet Details im Beitrag Scrum Master im Startup: Aufgaben, Modelle und Einstieg.
OKR und Scrum im Vergleich
Auf den ersten Blick ähneln sich beide Ansätze: Sie arbeiten in Zyklen, setzen auf Transparenz und regelmäßige Überprüfung. Der Fokus ist aber verschieden. OKR beantwortet die Frage nach dem Warum und Was auf Unternehmens- oder Teamebene. Scrum beantwortet die Frage nach dem Wie innerhalb eines Produktteams.
| Merkmal | OKR | Scrum |
|---|---|---|
| Zweck | Strategische Ziele setzen und messen | Produktentwicklung organisieren |
| Zyklus | Meist Quartal | Sprint, max. ein Monat |
| Reichweite | Ganzes Unternehmen, alle Abteilungen | Ein oder mehrere Produktteams |
| Messgröße | Wirkung (Outcome) | Fertiges Increment (Output) |
| Rollen | Keine festen Rollen, oft ein OKR-Verantwortlicher | Product Owner, Scrum Master, Developers |
Daraus ergibt sich die wichtigste Erkenntnis: Die beiden Frameworks konkurrieren nicht, solange du sie auf ihrer jeweiligen Ebene lässt. Probleme entstehen erst, wenn OKR zur Aufgabenliste wird oder Scrum-Teams ihre Sprint-Ziele ohne Bezug zur Unternehmensstrategie wählen.
So verbindest du die OKR-Methode mit Scrum
Die Brücke zwischen beiden Welten bilden das Product Goal und das Sprint Goal. Die Key Results des Quartals geben vor, welche Wirkung erzielt werden soll. Der Product Owner leitet daraus Prioritäten im Product Backlog ab, und jedes Sprint Goal sollte erkennbar auf mindestens ein Key Result einzahlen.
Schritt für Schritt zur Integration
- Quartals-OKR festlegen: Geschäftsführung und Teams einigen sich auf ein bis drei Objectives mit messbaren Key Results.
- Backlog ausrichten: Der Product Owner sortiert Einträge danach, welchen Beitrag sie zu den Key Results leisten.
- Sprint Goals verknüpfen: Im Sprint Planning formuliert das Team ein Sprint Goal und benennt das Key Result, auf das es zielt.
- Fortschritt im Review zeigen: Das Sprint Review zeigt nicht nur das Increment, sondern auch, ob sich die Kennzahlen bewegt haben.
- Lernen in der Retrospektive: Hat die Arbeit nicht gewirkt, wird das Vorgehen angepasst, nicht das Key Result kleingeredet.
Für die Einführung selbst gibt es verschiedene Wege: Manche Teams starten mit einer Tabelle und einem festen Termin pro Woche, andere nutzen spezialisierte Software. Wer die OKR-Methode einführen und sich vorher in Ruhe einlesen möchte, findet bei Anbietern wie Mooncamp, aber auch in Büchern wie John Doerrs „Measure What Matters“ ausführliche Anleitungen. Ein Tool lohnt sich meist erst, wenn mehrere Teams verknüpfte Ziele verfolgen.
Praxisbeispiel: SaaS-Startup mit zwölf Personen
Ein fiktives, aber typisches Beispiel: Ein Startup bietet eine Buchungssoftware für Physiotherapiepraxen an. Das Produktteam besteht aus einer Product Ownerin, vier Developers und einer Person, die nebenbei die Scrum-Master-Rolle übernimmt. Vertrieb und Support sind zusammen sechs Personen.
Das Quartals-Objective lautet: „Neue Praxen nutzen die Software ab Woche eins produktiv.“ Die Key Results:
- Anteil der Praxen, die in den ersten sieben Tagen mindestens 20 Termine buchen, steigt von 30 auf 50 Prozent.
- Supportanfragen im ersten Monat sinken von durchschnittlich sechs auf drei pro Praxis.
- Kündigungen im ersten Vertragsmonat gehen um ein Viertel zurück.
Das Produktteam arbeitet in Zwei-Wochen-Sprints. Sprint 1 zielt auf den Kalenderimport aus bestehenden Systemen, weil der Support zeigt, dass manuelles Übertragen der häufigste Abbruchgrund ist. Sprint 2 verbessert die Einrichtungsanleitung im Produkt. Im Sprint Review schauen alle gemeinsam auf die Aktivierungsquote. Der Vertrieb verfolgt parallel eigene Key Results, etwa ein Onboarding-Gespräch in der ersten Woche – ganz ohne Scrum.
Das Beispiel zeigt: OKR wirkt bereichsübergreifend, Scrum nur dort, wo ein Produkt entwickelt wird. Ein gemeinsamer Check-in pro Woche reicht, um beide Ebenen zu synchronisieren.
Chancen, Risiken und typische Fehler
Richtig kombiniert schaffen beide Frameworks Klarheit: Jede Person sieht, warum ihre Arbeit wichtig ist, und das Management erkennt, ob Investitionen in die Produktentwicklung tatsächlich wirken. Gerade in Startups, in denen sich Prioritäten schnell verschieben, hilft diese Verbindung beim Nein-Sagen.
Diese Fehler solltest du vermeiden
- Key Results als To-do-Liste: „Feature X bauen“ gehört ins Backlog, nicht in die OKR.
- Zu viele Ziele: Mehr als drei Objectives pro Team verwässern den Fokus.
- Doppelte Meetings: Ein separates OKR-Planning neben dem Sprint Planning ohne Abstimmung erzeugt Mehraufwand. Besser: OKR-Check-in kurz ins Sprint Review integrieren.
- OKR als Leistungsbeurteilung: Werden Boni an die Zielerreichung gekoppelt, setzen Teams vorsichtige Ziele.
- Fehlende Verantwortung: Ohne klare Zuständigkeit für den OKR-Prozess schläft er nach einem Quartal ein.
Wie Führung in jungen Teams solche Strukturen trägt, beleuchtet auch der Beitrag Die Leadership-Falle im Start-up. Wenn dein Team verteilt arbeitet, helfen dir außerdem die Tipps aus So baust du dein Remote-Startup auf.
Ab wann lohnt sich die Kombination?
Für ein Gründungsteam aus zwei oder drei Personen ist ein voller Scrum-Prozess oft zu schwer. Hier reichen meist eine einfache Wochenplanung und ein bis zwei Quartalsziele nach der OKR-Methode. Sobald ein eigenes Produktteam entsteht und daneben Vertrieb, Marketing oder Support wachsen, steigt der Nutzen: Dann braucht es ein gemeinsames Zielsystem, das über Abteilungsgrenzen funktioniert.
Eine pragmatische Faustregel: Beginne mit OKR auf Unternehmensebene, sobald du mehr als eine Handvoll Mitarbeitende hast. Führe Scrum ein, wenn mindestens drei Personen dauerhaft am selben Produkt entwickeln. Beide Ansätze kannst du schrittweise einführen und nach zwei Quartalen ehrlich bewerten.
Häufige Fragen
Wie funktioniert die OKR-Methode in der Praxis?
Zu Quartalsbeginn legen Führung und Teams wenige Objectives mit je drei bis fünf messbaren Key Results fest. Während des Quartals prüfen sie den Fortschritt in kurzen, regelmäßigen Check-ins. Am Ende werden die Key Results bewertet, und die Erkenntnisse fließen in die nächste Runde ein.
Welche Vorteile hat die OKR-Methode?
Sie schafft Fokus auf wenige Ziele, macht Prioritäten für alle sichtbar und verbindet Strategie mit messbarer Wirkung. Teams verstehen besser, wie ihre Arbeit zum Unternehmenserfolg beiträgt.
Ersetzt OKR das Sprint Goal?
Nein. Das Sprint Goal bleibt das Ziel eines einzelnen Sprints. Es sollte aber erkennbar auf ein Key Result einzahlen, damit die Arbeit des Teams eine strategische Richtung hat.
Wer ist für OKR in einem Scrum-Team zuständig?
In der Regel übernimmt der Product Owner die Verbindung zwischen Key Results und Product Backlog. Für den OKR-Prozess im gesamten Unternehmen ist oft eine Person aus Geschäftsführung oder Operations verantwortlich.
Fazit
Scrum und die OKR-Methode sind kein doppeltes Framework, sondern zwei Ebenen eines Systems. OKR gibt die Richtung für ein Quartal vor und misst Wirkung, Scrum liefert den Takt für die Umsetzung im Produktteam. Entscheidend ist die Verknüpfung über Product Goal und Sprint Goals sowie ein schlanker Rhythmus ohne parallele Meetings. Starte klein, beobachte nach zwei Quartalen, was funktioniert, und passe den Prozess an dein Team an.
