OKR und Scrum kombinieren, strategische Ziele wirksam in Sprints umsetzen

OKR und Scrum lösen unterschiedliche Probleme. Deshalb ist die Frage nach dem Unterschied richtig. Die wichtigere Frage lautet: Wofür brauche ich welches Instrument?

Scrum ist ein Rahmenwerk für die operative Projektarbeit. Es strukturiert, wie ein Team innerhalb kurzer Zyklen, den Sprints, konkrete Arbeitsergebnisse produziert. Scrum regelt Rollen wie Product Owner, Scrum Master und Entwicklungsteam, Ereignisse wie Sprint Planning, Daily, Review und Retrospektive sowie Artefakte wie Product Backlog, Sprint Backlog und Increment.

OKR ist ein Managementsystem für Ziele und Fokus. Es beantwortet die Frage: Woran soll eine Organisation, eine Abteilung oder ein Team in den nächsten 90 Tagen arbeiten, und woran erkennen wir, ob wir erfolgreich waren? OKR regelt keine Arbeitsabläufe, sondern die Zielausrichtung.

Kurz: Scrum beantwortet das Wie der Arbeit. OKR beantwortet das Wofür. Beide Systeme können unabhängig voneinander existieren. Und sie können sich sinnvoll ergänzen.

Ja. In der Praxis ist die Kombination häufig sinnvoller als die isolierte Nutzung eines der beiden Systeme.

Das Grundprinzip der Kombination lautet: OKR gibt die strategische Richtung vor. Scrum liefert die operative Struktur, um genau diese Ziele in konkreten Arbeitsschritten zu verfolgen.

Ein typisches Zusammenspiel sieht so aus: Die OKRs eines Quartals bestimmen, welche Epics und User Stories in das Product Backlog aufgenommen und priorisiert werden. Im Sprint Planning wird entschieden, welche Backlog-Einträge im nächsten Sprint umgesetzt werden. Der Bezug zu den laufenden OKRs bleibt dabei sichtbar.

In der Sprint Retrospektive kann gefragt werden: Kommen wir mit unserem Tempo voran, um die Key Results des Quartals zu erreichen?

Die Kombination funktioniert besonders gut, wenn OKRs auf Teamebene definiert werden und wenn der Product Owner die Verbindung zwischen strategischen Zielen und Backlog-Priorisierung aktiv gestaltet.

Nein. Weder OKR ersetzt Scrum, noch ersetzt Scrum OKR.

Ein verbreitetes Missverständnis entsteht, weil beide Systeme mit Zyklen, Transparenz und Fokus arbeiten. Auf den ersten Blick wirken sie ähnlich. Der Unterschied liegt jedoch in der Ebene, auf der sie wirken.

Scrum wirkt auf der Teamebene. Es strukturiert, wie ein Team organisiert ist und wie es täglich zusammenarbeitet. Scrum ohne ein übergeordnetes Zielsystem kann dazu führen, dass Teams sehr effizient an Dingen arbeiten, die strategisch nicht priorisiert sein sollten.

OKR wirkt auf der Organisations- und Führungsebene. Es stellt sicher, dass Energie und Ressourcen auf die wirklich wichtigen Ziele konzentriert werden. OKR ohne funktionierende Arbeitsstruktur bleibt oft abstrakt. Ziele werden formuliert, aber nicht wirksam verfolgt.

Wer beides einsetzt, bekommt Richtung durch OKR und Umsetzungskraft durch Scrum. Diese beiden Dinge treten in der Praxis häufig getrennt auf und müssen deshalb sauber verbunden werden.

Das ist eine der konkretesten Herausforderungen in der Kombination. Sie ist lösbar, wenn einige Grundprinzipien beachtet werden.

OKR arbeitet typischerweise in Quartalszyklen von rund 90 Tagen. Scrum-Sprints dauern üblicherweise 1 bis 4 Wochen. Bei zweiwöchigen Sprints ergeben sich etwa 6 bis 7 Sprints pro OKR-Quartal.

Die empfohlene Synchronisation: OKR-Ziele werden zu Beginn des Quartals festgelegt, idealerweise bevor der erste Sprint des Quartals startet. Das Product Backlog wird dann im Licht der neuen OKRs priorisiert.

Nach jedem Sprint oder spätestens nach 3 bis 4 Sprints sollte ein kurzes OKR-Check-in stattfinden. Welche Key Results haben wir bereits erreicht? Wo liegen wir zurück? Muss das Backlog neu priorisiert werden?

Zum Quartalsende findet das OKR-Review statt. Dieses kann mit dem letzten Sprint-Review des Quartals zusammengelegt werden, um Doppelaufwand zu vermeiden.

Ein häufiger Fehler: OKR-Ziele werden festgelegt, aber das Sprint Planning ignoriert sie. Dann laufen beide Systeme nebeneinander her, ohne sich gegenseitig zu stärken. Teams empfinden OKR dann als zusätzliche Bürokratie.

Diese Frage berührt einen der häufigsten Rollenkonflikte in der Praxis.

Im reinen Scrum trägt der Product Owner die Verantwortung für das Product Backlog und damit für die Priorisierung der Arbeit. Im OKR-System tragen Teams und Führungskräfte gemeinsam Verantwortung für Ziele. OKR ist kein reines Top-down-System.

In der Kombination ergibt sich eine klare Aufteilung: Die Führungsebene, also Geschäftsführung oder Bereichsleitung, definiert die strategischen OKRs auf Unternehmens- oder Bereichsebene. Das Team leitet daraus unter Beteiligung des Product Owners eigene Team-OKRs ab und entscheidet, wie diese in Sprint-Arbeit übersetzt werden.

Der Product Owner ist dann das operative Scharnier. Er übersetzt Team-OKRs in Backlog-Prioritäten und stellt sicher, dass Sprints nicht von strategiefremden Themen dominiert werden.

In der öffentlichen Verwaltung kommt eine zusätzliche Komplexität hinzu: Projekte sind oft durch gesetzliche Aufträge, Haushaltsvorgaben oder Beschlüsse von außen vorgegeben. Hier braucht es eine klare Abgrenzung, welche Ziele wirklich durch OKR steuerbar sind und welche schlicht Pflichtaufgaben sind.

Ja. Das ist sogar der häufigere Fall.

OKR ist kein agiles Framework und setzt keine agile Arbeitsweise voraus. Unternehmen und Behörden führen OKR erfolgreich ein, ohne Scrum zu nutzen. Das funktioniert in traditionellen Projektstrukturen, in Linienabteilungen ohne Produktentwicklung und in Organisationen mit traditionellem Projektmanagement.

OKR braucht keine Sprints, kein Backlog und keine Scrum-Rollen. OKR braucht klare Objectives, messbare Key Results, einen regelmäßigen Check-in-Rhythmus und Führungskräfte, die Verbindlichkeit vorleben.

Umgekehrt gilt: Scrum-Teams ohne OKR arbeiten oft fokussiert und gut organisiert. Sie wissen aber nicht immer, ob ihre Arbeit die strategisch wichtigen Themen der Organisation voranbringt. OKR löst dieses Problem, ohne die bestehende Scrum-Struktur zu ersetzen.

Kurz: OKR ohne Scrum ist möglich und weit verbreitet. Scrum ohne OKR ist ebenfalls möglich. Auf Dauer ist es riskant, wenn keine anderen Zielsysteme vorhanden sind.

Ja. Allerdings braucht die Kombination Anpassungen an die besonderen Rahmenbedingungen des öffentlichen Sektors.

In der öffentlichen Verwaltung sind viele Projekte durch gesetzliche Aufträge, Haushaltspläne, Beschlüsse und Berichtspflichten vordefiniert. Das bedeutet nicht, dass OKR oder Scrum nicht funktionieren. Beide Systeme müssen aber auf diese Realität angepasst werden.

Für OKR in der Verwaltung gilt: Nicht alle Aufgaben lassen sich als ambitionierte OKRs formulieren. Pflichtaufgaben bleiben Pflichtaufgaben. OKR eignet sich besonders für Transformations- und Entwicklungsziele. Beispiele sind bessere digitale Bürgerservices, kürzere Bearbeitungszeiten in bestimmten Prozessen oder stärkere abteilungsübergreifende Zusammenarbeit.

Für Scrum in der Verwaltung gilt: Sprint-Zyklen müssen mit Entscheidungs- und Genehmigungsprozessen kompatibel sein, die in Behörden oft länger dauern als in Unternehmen. Auch die Scrum-Rollen, insbesondere der Product Owner mit Entscheidungsbefugnis, müssen institutionell verankert sein.

In Kombination gibt OKR verwaltungsinternen Projekten einen strategischen Rahmen, der über den einzelnen Haushalt hinausweist. Scrum liefert die Struktur, um komplexe Umsetzungsprojekte, etwa im Rahmen der Digitalisierung, iterativ und anpassungsfähig voranzubringen.

Es gibt vier Fehler, die in der Praxis besonders häufig auftreten.

Fehler 1: OKR und Sprints laufen entkoppelt.
OKR-Ziele werden quartalsweise definiert, aber das Sprint Planning orientiert sich nicht daran. Teams arbeiten fleißig, aber nicht auf die OKRs hin. OKR wirkt dann wie ein Parallelsystem ohne Konsequenz.

Fehler 2: Zu viele OKRs auf Teamebene.
Teams definieren 5 bis 7 Objectives mit je 3 bis 5 Key Results. Das Product Backlog wird dadurch unsteuerbar, weil jeder Sprint theoretisch allen OKRs dienen müsste. Besser sind maximal 1 bis 2 Team-OKRs pro Quartal, die wirklich fokussiert verfolgt werden.

Fehler 3: Der Product Owner wird zum OKR-Beauftragten erklärt.
OKR ist kein Job für eine Person. OKR ist ein Teamprozess. Wenn der Product Owner allein für die Verbindung zwischen OKR und Backlog verantwortlich gemacht wird, entsteht ein Bottleneck. Das Team verliert Eigenverantwortung.

Fehler 4: OKR-Reviews und Sprint-Reviews werden doppelt durchgeführt.
Das erzeugt Meetingmüdigkeit. Sinnvoller ist: Das letzte Sprint-Review eines Quartals wird zum kombinierten OKR-Review erweitert. Ein Meeting, zwei Funktionen.

Für Scrum existieren etablierte Zertifizierungspfade. Dazu gehören Certified Scrum Master, Professional Scrum Master, Professional Scrum Product Owner und weitere Formate. Diese fokussieren auf das Scrum-Framework und seine Anwendung in der Softwareentwicklung oder Produktentwicklung.

Für OKR gibt es keine einheitliche, branchenübergreifend anerkannte Zertifizierung. Es gibt jedoch qualifizierte Weiterbildungsformate, die auf die Einführung und Steuerung von OKR in Organisationen vorbereiten.

Das OKR Professional Seminar an der Erasmus Hochschule Basel schließt mit einem akademisch anerkannten Zertifikat mit 2 ECTS ab. Es ist explizit auf Führungskräfte und interne OKR-Verantwortliche ausgerichtet.

Ob separate Trainings nötig sind, hängt von der Rolle ab. Ein Scrum Master, der OKR einführen soll, braucht keine zweite Scrum-Zertifizierung, sondern ein gutes OKR-Training. Ein Bereichsleiter, der OKR und Scrum parallel steuern will, braucht vor allem ein Verständnis dafür, wie beide Systeme auf Managementebene zusammenwirken. Operative Scrum-Tiefe ist dafür weniger entscheidend.

Die ehrliche Antwort: Beide Systeme gleichzeitig einzuführen ist anspruchsvoll und in den meisten Fällen nicht empfehlenswert.

Für Organisationen ohne Vorerfahrung ist die bessere Reihenfolge: Scrum zuerst, dann OKR. Scrum schafft zunächst Struktur, Transparenz und ein gemeinsames Vokabular auf Teamebene. Wenn Teams stabil in Scrum-Zyklen arbeiten, ist die Einführung von OKR als strategisches Überbausystem deutlich leichter. Die nötige Disziplin für regelmäßige Check-ins und Reviews ist dann bereits etabliert.

Für Organisationen, die bereits agil arbeiten, aber keine klare strategische Zielsteuerung haben, kann OKR als eigenständiges System auf Führungsebene eingeführt werden. Das bestehende Scrum-Setup muss dafür nicht verändert werden. Die Integration folgt schrittweise.

Für Organisationen, die bereits OKR nutzen, aber keine strukturierte Umsetzungsebene haben, kann Scrum oder ein leichteres agiles Framework wie Kanban als operative Ergänzung eingeführt werden. So wird die Lücke zwischen Quartalszielen und täglicher Arbeit geschlossen.

In jedem Fall gilt: Der größte Fehler ist, beide Systeme gleichzeitig zu implementieren, ohne klare Verantwortlichkeiten und ohne ausreichende Begleitung. Hier lohnt sich externe Unterstützung für die konzeptionelle Verknüpfung beider Systeme und für die Einführung im Team.