Scrum einführen: Der praktische 90-Tage-Plan für Teams

“Ab Montag machen wir Scrum” — und zwei Monate später ist davon nur noch das Daily übrig. Die meisten Scrum-Einführungen scheitern nicht an der Methode, sondern am fehlenden Plan. In 90 Tagen kannst du den Unterschied machen — wenn du weißt, wie.

Diese 90 Tage sind der erste konkrete Schritt einer agilen Transformation. Du legst das Fundament für ein Team, das nicht nur Scrum “macht”, sondern agil arbeitet. Nach diesen 90 Tagen beginnt die eigentliche Skalierung — aber ohne diesen stabilen Start ist jede Transformation zum Scheitern verurteilt.

Warum 90 Tage?

Scrum einführen ist keine Sache von einer Woche. Aber auch kein Jahresprojekt. 90 Tage sind der Sweet Spot:

• Kurz genug, um Momentum zu halten
• Lang genug, um echte Veränderung zu verankern
• Drei Monate = etwa 6-8 Sprints mit typischen Zwei-Wochen-Zyklen

Das Ziel nach 90 Tagen: Ein Team, das selbstständig in Sprints arbeitet, regelmäßig liefert und sich kontinuierlich verbessert.

Bevor du startest: Ist Scrum überhaupt das Richtige für dein Team? Der Scrum vs. Kanban Vergleich hilft bei der Entscheidung.

Phase 1: Fundament legen (Tag 1-30)

Woche 1-2: Verstehen und Entscheiden

Bevor du loslegst, kläre die Grundlagen:

• Warum Scrum? Was soll besser werden? Ohne klares Ziel wird jede agile Transformation zur Methodenübung ohne Wirkung.
• Was bedeutet agil? Scrum ist ein Framework, aber die Denkweise dahinter kommt aus dem Agilen Manifest. Wer die vier Werte und zwölf Prinzipien nicht kennt, versteht nicht, warum Scrum so funktioniert, wie es funktioniert.
• Wer macht mit? Identifiziere das Pilotteam. Ein Team reicht für den Start.
• Wer trägt es? Du brauchst Management-Support. Nicht als Lippenbekenntnis, sondern echte Rückendeckung.

Woche 3-4: Training und Setup

• Scrum-Schulung für das gesamte Pilotteam – nicht nur für den Scrum Master
• Rollen klären: Wer ist Product Owner? Wer Scrum Master? Das Team?
• Tools einrichten: Jira, Trello oder ein physisches Board – Hauptsache, alle können es nutzen
• Erstes Backlog aufbauen: Der Product Owner priorisiert erste User Stories. Der User Story Aufbau Guide zeigt, wie gute Stories aussehen.

Typische Stolpersteine:

• Scrum Master und Product Owner sind dieselbe Person (funktioniert nicht)
• Backlog ist eine Feature-Wunschliste statt priorisierter Arbeit
• Team wird nicht von anderer Arbeit freigestellt

Phase 2: Erste Sprints meistern (Tag 31-60)

Sprint 1-2: Laufen lernen

Jetzt wird es ernst. Der erste Sprint ist nicht perfekt – und das ist okay.

Sprint Planning:

• Wie viel Arbeit kann das Team realistisch schaffen?
• Niemand weiß das am Anfang. Schätzt konservativ.

Daily Scrum:

• 15 Minuten, jeden Tag, zur gleichen Zeit
• Fokus: Was blockiert uns?

Sprint Review:

• Zeigt, was fertig ist – nicht was “fast fertig” ist
• Stakeholder einladen, Feedback sammeln

Retrospektive:

• Was lief gut? Was nicht? Was ändern wir?
• Zeit zur Reflextion und gemeinsamem Lernen. Der wichtigste Termin, um über eure Erfahrungen während der Einführung von Scrum zu sprechen.

Sprint 3-4: Rhythmus finden

Ab jetzt wiederholt sich der Zyklus. Das Team:

• Verbessert die Schätzungen (Velocity stabilisiert sich)
• Findet seinen eigenen Arbeitsrhythmus
• Lernt, was “Done” wirklich bedeutet

Change Management ist jetzt kritisch: Alte Gewohnheiten kommen zurück. Manager wollen “kurz nachfragen”. Andere Projekte fordern Ressourcen. Das ist kein Versagen — es ist ein natürlicher Reflex, in vertraute Muster zurückzufallen. Umso wichtiger ist ein Scrum Master oder Agile Coach, der das Team darauf aufmerksam macht und kontinuierlich an einem gemeinsamen Verständnis für Scrum und agiles Denken arbeitet.

Phase 3: Stabilisieren und Optimieren (Tag 61-90)

Metriken einführen

Jetzt ist der richtige Zeitpunkt für Zahlen:

• Velocity: Wie viel schafft ihr pro Sprint?
• Sprint Burndown: Liegt ihr im Plan?
• Cycle Time: Wie lange dauert eine Story von Anfang bis Ende?

Wichtig: Metriken sind für das Team, nicht fürs Management-Reporting. Sie helfen bei der Selbstverbesserung.

Prozess verfeinern

Nach 4-6 Sprints wisst ihr, wo es hakt:

• Definition of Done konkretisieren — der Akzeptanzkriterien Guide hilft dabei
• Sprint-Länge anpassen (falls nötig)
• Meetings optimieren – kürzer, fokussierter
• Backlog Refinement als regelmäßigen Termin etablieren

Skalierung vorbereiten

Wenn das Pilotteam läuft, kommen die Fragen: “Können wir das auch?” Dokumentiert eure Learnings:

• Was hat funktioniert?
• Welche Fehler sollten andere vermeiden?
• Welche Anpassungen waren nötig?

Die häufigsten Fehler bei der Scrum-Einführung

1. “Wir machen Scrum, aber ohne Sprints”

Sprints sind das Herzstück von Scrum — nicht weil sie im Guide stehen, sondern weil sie einen Rhythmus etablieren, der Lernen ermöglicht. Ohne feste Zeitboxen gibt es keinen klaren Punkt, an dem das Team innehält und reflektiert: Was haben wir geschafft? Was nicht? Was ändern wir?

Teams, die Sprints weglassen, arbeiten oft in einem endlosen Fluss von Aufgaben. Das fühlt sich zunächst flexibler an, verhindert aber genau die regelmäßigen Feedback-Schleifen, die Scrum so wirkungsvoll machen. Der Sprint zwingt zur Priorisierung, zur Fokussierung und zur ehrlichen Bestandsaufnahme.

2. “Der Scrum Master macht das nebenbei”

Die Rolle des Scrum Masters wird oft unterschätzt. Es reicht nicht, Meetings zu moderieren und ein Board zu pflegen. Ein guter Scrum Master beobachtet die Teamdynamik, erkennt Hindernisse bevor sie eskalieren, coacht Einzelne und das Team, und schützt den Sprint vor Störungen von außen.

Das alles braucht Zeit — mindestens 50% Kapazität für ein Team, in der Einführungsphase eher mehr. Wenn der Scrum Master “das nebenbei macht”, passiert in der Praxis meist nichts davon. Die Meetings finden statt, aber die eigentliche Arbeit — das Coaching, die Verbesserung, das Hindernisse-Beseitigen — bleibt liegen.

3. “Das Management bestimmt die Sprint-Inhalte”

In Scrum gibt es eine klare Trennung: Der Product Owner entscheidet, was als nächstes wichtig ist. Das Team entscheidet, wie viel es in einem Sprint realistisch umsetzen kann. Wenn das Management diese Grenze überschreitet und vorgibt, was im Sprint zu sein hat, passieren zwei Dinge.

Erstens: Das Team verliert die Ownership über seine Arbeit. Warum einen realistischen Forecast abgeben, wenn die Entscheidung ohnehin von oben kommt? Zweitens: Die Schätzungen werden wertlos. Das Team lernt nicht, seine eigene Kapazität einzuschätzen, weil es nie die Chance bekommt, selbst zu entscheiden. Das Ergebnis sind überfüllte Sprints, verfehlte Ziele und frustrierte Teams.

4. “Wir haben keine Zeit für Retrospektiven”

Wenn ein Event gestrichen wird, ist es meist die Retrospektive. Die Argumentation klingt logisch: “Wir haben so viel zu tun, wir können uns keine zwei Stunden Nabelschau leisten.” Aber genau das ist der Denkfehler.

Die Retrospektive ist das einzige Event, das sich explizit mit der Verbesserung der Zusammenarbeit beschäftigt. Ohne sie wiederholt das Team dieselben Fehler, trägt dieselben Frustrationen mit sich, und die kleinen Reibungsverluste summieren sich zu großen Ineffizienzen. Teams, die ihre Retros ausfallen lassen, arbeiten vielleicht schneller — aber sie werden nicht besser. Und genau das ist der Punkt von Scrum.

Wann du externe Unterstützung brauchst

Manche Teams schaffen die Einführung selbst. Für andere macht ein externer Agile Coach oder Trainer Sinn:

• Beim Kickoff: Ein erfahrener Trainer vermittelt die Grundlagen schneller und korrekter
• Bei Widerständen: Ein Externer kann Konflikte moderieren, die intern schwierig sind
• Nach dem Start: Ein Coach hilft, frühe Fehler zu korrigieren, bevor sie sich verfestigen

Der richtige Zeitpunkt für externe Hilfe ist vor den Problemen – nicht erst, wenn die Einführung gescheitert ist.

Dein 90-Tage-Fahrplan zusammengefasst

Nach 90 Tagen solltest du ein Team haben, das:

• Eigenständig in Sprints arbeitet
• Regelmäßig liefernde Inkremente produziert
• Sich kontinuierlich selbst verbessert
• Die Scrum-Events als wertvoll empfindet (nicht als Pflichttermine)

Fazit: 90 Tage für den Grundstein

Die Einführung von Scrum ist kein Selbstläufer. Die meisten Teams, die scheitern, haben nicht zu wenig gelesen — sie haben zu schnell losgelegt. Ein strukturierter 90-Tage-Plan verhindert die typischen Fehler und legt das Fundament für nachhaltige Veränderung.

Die drei wichtigsten Takeaways:

1. Fundament vor Geschwindigkeit — Die ersten 30 Tage sind entscheidend. Rollen, Training und Management-Support müssen stehen, bevor der erste Sprint startet.

2. Change Management ist Kernarbeit — Ab Sprint 3 kommen die alten Gewohnheiten zurück. Hier zeigt sich, ob die Einführung gelingt oder zur Methodenübung verkommt.

3. Dokumentieren für Skalierung — Eure Learnings sind Gold wert für das nächste Team. Schreibt auf, was funktioniert hat und was nicht.

Weiterführende Artikel:

• User Story Aufbau — Das richtige Format für dein erstes Backlog
• Akzeptanzkriterien Guide — Definition of Done konkretisieren
• Scrum vs. Kanban — Die richtige Methode für dein Team