Agiles Projektmanagement mit Scrum: Ablauf, Rollen und Grenzen

Was agiles Projektmanagement mit Scrum ausmacht

Drei Dinge unterscheiden das Vorgehen vom klassischen Projektmanagement:

• Iterativ statt einmalig geplant. Geplant wird fortlaufend und in kurzen Zyklen, nicht einmal zu Beginn für die gesamte Laufzeit.
• Kontinuierlich statt am Ende geliefert. Am Ende jeder Iteration steht ein nutzbarer Stand, nicht erst zum Projektabschluss ein fertiges Produkt.
• Verantwortung im Team statt in einer Rolle. Klassisches Projektmanagement bündelt Verantwortung bei der Projektleitung; Scrum verteilt sie auf Product Owner, Scrum Master und Entwicklungsteam.

Der Unterschied ist damit kein methodischer Selbstzweck, sondern eine Antwort auf Unsicherheit: Wo Anforderungen sich im Verlauf ändern, ist ein Vorgehen, das Lernen einplant, dem Plan überlegen, der es nicht tut.

Wann Scrum passt – und wann nicht

Agile Vorgehensweisen sind kein Selbstzweck. Nicht jedes Projekt profitiert davon, bestehende Strukturen aufzulösen oder strikt nach einem Framework zu arbeiten.

Scrum spielt seine Stärken dort aus, wo Anforderungen unklar oder veränderlich sind: Softwareentwicklung, Produktentwicklung, kreative Wissensarbeit mit hoher Komplexität. Bei fixen Anforderungen, gesetzlichen Vorgaben oder linearen Lieferketten entsteht dagegen Aufwand ohne Gegenwert – dort sind hybride oder klassische Ansätze meist die bessere Wahl. Die grundlegenden Unterschiede beider Welten haben wir in klassische und agile Organisations- und Arbeitsformen gegenübergestellt.

In vielen Vorhaben entsteht die größte Wirksamkeit deshalb nicht durch die reine Lehre, sondern dort, wo agile Elemente gezielt in ein bestehendes Projekt- oder Organisationssetup eingebettet werden: Rollen, Meetings und Verantwortlichkeiten aus Scrum bleiben erhalten, ergänzt um die Elemente klassischer Projektarbeit, die Scrum offenlässt – eine saubere Projektbeauftragung und eine explizite Startphase.

Der Ablauf in sieben Schritten

Der folgende Ablauf zeigt beispielhaft, wie sich ein solcher hybrider Ansatz aufbauen lässt. Er ist kein starres Vorgehensmodell, sondern ein Orientierungsrahmen.

1. Vision

Ausgangspunkt ist eine fachliche oder strategische Vision des Auftraggebers (z. B. Geschäftsführung, Fachbereich oder externer Kunde). Diese Vision dient als Gesprächsgrundlage, um Machbarkeit, Zielrichtung und erste Rahmenbedingungen gemeinsam mit dem Projektteam zu klären.

2. Project Inception

In einer frühen Startphase wird ein initiales Projektteam gebildet, typischerweise bestehend aus Product Owner und Scrum Master sowie einzelnen Teammitgliedern mit ausreichendem Domänen- und Systemverständnis.

Ziel dieser Phase ist nicht Detailplanung, sondern Struktur: Die Vision wird konkretisiert, zentrale Annahmen werden geprüft und wesentliche Rahmenbedingungen festgelegt – etwa die Priorisierung von Umfang, Qualität, Budget und Zeit. Parallel entsteht eine erste Grobstruktur des Backlogs.

Abhängig vom Kontext kann bereits hier eine initiale Aufwandseinschätzung sinnvoll sein. Wichtig ist dabei, dass Schätzungen von den Personen vorgenommen werden, die später auch an der Umsetzung beteiligt sind.

Mit der formalen Genehmigung dieser Rahmenbedingungen erfolgt der Projektstart. Das ist der Punkt, den reines Scrum nicht abdeckt – und der in klassisch geprägten Organisationen den Unterschied macht, ob ein agiles Projekt überhaupt beauftragt werden kann.

3. Backlog strukturieren

Im nächsten Schritt wird das Product Backlog aufgebaut. Zunächst auf höherer Ebene, etwa in Form von übergeordneten Themen oder Master Stories; die Detaillierung in konkrete User Stories erfolgt schrittweise.

Was ist das Backlog?
Das Product Backlog bündelt alle Anforderungen in priorisierter Form. Es wird vom Product Owner gepflegt und dient als zentrales Steuerungsinstrument.

Diese Phase erstreckt sich häufig über einen oder mehrere kurze Sprints. Analytische Arbeit, etwa in Form von Spikes, hilft dabei, fachliche und technische Unsicherheiten früh sichtbar zu machen.

4. Vorbereitung des ersten Sprints

Parallel zum Aufbau des Backlogs wird der erste Sprint vorbereitet. Dafür werden die User Stories identifiziert, die für einen sinnvollen Start notwendig sind, ausreichend verstanden und grob geschätzt.

Was ist ein Sprint?
Ein Sprint ist eine zeitlich festgelegte Iteration. Entscheidend ist nicht Geschwindigkeit, sondern ein stabiler Arbeitsrhythmus, der kontinuierliches Feedback ermöglicht.

Planung ist wichtig, sollte jedoch bewusst begrenzt bleiben. Ziel ist es, handlungsfähig zu werden, nicht maximale Vorhersage zu erzeugen. Weitere Planung erfolgt iterativ im Verlauf der Umsetzung.

5. Der Sprint-Zyklus

Mit Beginn des ersten Sprints arbeitet das Team iterativ am Product Backlog. In Estimation Meetings werden weitere Backlog-Einträge konkretisiert, diskutiert und geschätzt.

6. Roadmap und Release-Sicht

Während das Team liefert, überführt der Product Owner die verfügbaren Backlog-Strukturen in eine Roadmap und einen groben Releaseplan. Beide Artefakte werden fortlaufend überprüft und angepasst – sie sind Kommunikationsmittel gegenüber der Auftraggeberseite, keine Zusage.

7. Inkrementelle Produktentstehung

Ziel bleibt es, am Ende jedes Sprints einen nutzbaren Stand des Produkts zu erzeugen. In vielen Projekten bedeutet das zunächst interne oder testbare Versionen, die entlang eines Releaseplans zusammengeführt werden.

Durch regelmäßige Abstimmung und Feedback entsteht kein Überraschungsmoment am Projektende, sondern ein Ergebnis, das für Auftraggeber und Team nachvollziehbar gewachsen ist.

Fazit

Agiles Projektmanagement mit Scrum funktioniert in klassisch geprägten Organisationen selten als reine Lehre und fast immer als bewusste Kombination: Scrum liefert den Takt für die Umsetzung, die klassische Projektwelt liefert Beauftragung und Rahmen. Wer beides trennt statt gegeneinander auszuspielen, bekommt ein Vorgehen, das im Unternehmen anschlussfähig bleibt – und trotzdem iterativ arbeitet.

Welches Vorgehensmodell zu deinem Projekt passt, klärt die Entscheidungshilfe im Beitrag Wann welche Projektmanagement Methode.