Wenn Scrum allein nicht reicht: Agiles Projektmanagement im Kontext

Entscheidend ist der Kontext: Es gibt grundlegende Unterschiede zwischen klassischen und agilen Organisations- und Arbeitsformen . In vielen Vorhaben entsteht die größte Wirksamkeit dort, wo agile Elemente gezielt in ein bestehendes Projekt- oder Organisationssetup eingebettet werden.

Ein häufig genutzter Ansatz ist die Kombination von agilem Projektmanagement mit Scrum . Rollen, Meetings und Verantwortlichkeiten aus Scrum bleiben dabei erhalten. Ergänzt werden sie um strukturelle Elemente, die klassische Projektarbeit adressieren, etwa eine saubere Projektbeauftragung und eine explizite Startphase.

Der folgende Ablauf zeigt beispielhaft, wie sich ein solcher hybrider Ansatz strukturiert aufbauen lässt. Er ist nicht als starres Vorgehensmodell zu verstehen, sondern als 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 (z. B. 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 tatsächlich an der Umsetzung beteiligt sind.

Mit der formalen Genehmigung dieser Rahmenbedingungen erfolgt der Projektstart .

3. Backlog strukturieren

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

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.

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.

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.

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.

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

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.

7. Inkrementelle Produktentstehung

Ziel bleibt es, am Ende jedes Sprints einen nutzbaren Stand des Produkts zu erzeugen. In vielen Projekten bedeutet dies 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.