PMI PMP: Agile, Scrum & Hybride Bereitstellung — Lernleitfaden

By Laurynas Brazys · 21 July 2026 · #pmi #pmp #certification #exam-prep #study-guide

Teil des PMP — Lernleitfaden. Üben Sie mit verifizierten Antworten im PMI-Prüfungscenter, oder absolvieren Sie zeitlich begrenzte Übungstests auf ExamRoll.io.

Scrum-Rollen, -Zeremonien und -Artefakte

Scrum arbeitet bewusst mit einer kleinen Rollenstruktur, da die Diffusion von Verantwortlichkeit einer der Hauptgründe für das Scheitern komplexer Projekte ist. Der Product Owner ist für das Was und das Warum verantwortlich: Er definiert den Wert, priorisiert das Backlog und hat die Befugnis, Inkremente zu akzeptieren oder abzulehnen. Der Scrum Master ist dafür verantwortlich, wie gut der Prozess abläuft: Er ist ein Servant-Leader, der Hindernisse beseitigt, das Team in agilen Praktiken coacht und es vor Störungen schützt. Die Developers (das gesamte Lieferteam, nicht nur Programmierer) sind für das Wie verantwortlich: Sie organisieren sich selbst, um Backlog-Items in jedem Sprint in ein funktionierendes Inkrement umzuwandeln.

Diese Rollen müssen von echten, engagierten Personen besetzt werden. Ein unengagierter oder abwesender Product Owner ist eines der destruktivsten Muster in der agilen Entwicklung – ohne seine Echtzeit-Priorisierung und -Abnahme werden Sprint Reviews zu Status-Meetings anstatt zu Events zur Wertvalidierung, Feedback-Schleifen verlängern sich und das Team driftet dahin ab, das Falsche zu bauen. Wenn man mit einem abwesenden PO konfrontiert ist, ist die richtige Vorgehensweise, dies an den Sponsor zu eskalieren und die Rolle neu zu etablieren, anstatt den Scrum Master dauerhaft als Stellvertreter für Entscheidungen einzusetzen.

Die Kernzeremonien bilden eine geschlossene Feedback-Schleife:

• Sprint Planning
  • Zweck: Sprint-Ziel und Forecast aushandeln
  • Frequenz: Zu Beginn des Sprints
  • Primäres Ergebnis: Sprint Backlog
• Daily Standup
  • Zweck: Synchronisieren, Hindernisse aufzeigen
  • Frequenz: Täglich, Timebox von 15 Min.
  • Primäres Ergebnis: Angepasster Plan für den Tag
• Sprint Review
  • Zweck: Das Inkrement mit den Stakeholdern inspizieren
  • Frequenz: Am Ende des Sprints
  • Primäres Ergebnis: Feedback, aktualisiertes Product Backlog
• Sprint Retrospective
  • Zweck: Den Prozess inspizieren
  • Frequenz: Am Ende des Sprints
  • Primäres Ergebnis: Konkrete Verbesserungsmaßnahmen

Die Artefakte – Product Backlog, Sprint Backlog und Inkrement – haben jeweils eine zugehörige Selbstverpflichtung (Commitment): das Product Goal (Produkt-Ziel), das Sprint Goal (Sprint-Ziel) bzw. die Definition of Done. Diese Commitments verhindern, dass Scrum zu einem „iterativen Wasserfallmodell“ verkommt.

Backlog-Management und User Stories

Das Product Backlog ist eine lebende, geordnete Liste – kein Spezifikationsdokument, das zu Projektbeginn eingefroren wird. Der Product Owner pflegt es in Zusammenarbeit mit dem Team und verfeinert die Items, sodass die obersten Einträge im Backlog klein, gut verstanden und bereit sind, in den Sprint gezogen zu werden. Eine übliche Kadenz ist, in jedem Sprint 5–10 % der Teamkapazität für das Backlog Refinement aufzuwenden.

User Stories folgen dem bekannten Muster: Als [Persona] möchte ich [Fähigkeit], damit [Nutzen]. Der Teil mit dem Nutzen ist genauso wichtig wie die Fähigkeit – er ermöglicht es dem Team, alternative Lösungen vorzuschlagen, und befähigt den PO zu entscheiden, ob die Story bei sich ändernden Prioritäten immer noch den Aufwand wert ist.

Akzeptanzkriterien sind die beobachtbaren, testbaren Bedingungen, unter denen der PO die Story akzeptieren wird. Sie unterscheiden sich von der Definition of Done: Akzeptanzkriterien sind story-spezifisch (Wird der Anmeldebildschirm nach fünf fehlgeschlagenen Versuchen gesperrt?), während die DoD universell für jede Story gilt (Wurde ein Code-Review durchgeführt, wurde es getestet, dokumentiert, auf Staging bereitgestellt?).

Wenn ein Stakeholder mitten im Projekt eine neue Anforderung einbringt – selbst eine, die früherer Arbeit ähnelt – sollte der PO nicht einfach ein Datum herausplatzen. Die richtige Reaktion ist, die Anfrage als potenzielles Backlog-Item zu erfassen, es mit dem Team zu schätzen (vielleicht unter Verwendung von Referenz-Stories als Anker für eine relative Schätzung) und es dann entsprechend seinem Wert im Verhältnis zu bestehenden Items im Backlog zu platzieren. Eine frühere Ähnlichkeit beschleunigt die Schätzung, umgeht aber nicht das Gespräch über die Priorisierung.

DoR, DoD und Iterationsplanung

Die Definition of Ready (DoR) ist ein Gate für den Eintritt in einen Sprint. Eine Story ist „ready“, wenn sie klein genug ist, um innerhalb eines Sprints abgeschlossen zu werden, klare Akzeptanzkriterien hat, bekannte Abhängigkeiten identifiziert sind und sie vom Team verstanden wird. Die Durchsetzung der DoR verhindert, dass das Team unausgereifte Arbeit in den Sprint zieht, die mitten im Sprint wegen unbeantworteter Fragen ins Stocken gerät.

Die Definition of Done (DoD) ist ein Gate für den Austritt. Sie ist die gemeinsame, nicht verhandelbare Checkliste, die ein „Wir sind mit dem Programmieren fertig“ in „Dies ist ein potenziell auslieferbares Inkrement“ umwandelt. Eine robuste DoD umfasst typischerweise bestandene automatisierte Tests, Code-Reviews, saubere Sicherheitsscans, aktualisierte Dokumentation und – ganz entscheidend – die Berücksichtigung nicht-funktionaler Anforderungen wie Performance und Observability. Die Einbeziehung von Operations und QA bei der Definition der DoD verhindert das Muster, bei dem ein Inkrement im Sprint Review „funktioniert“, aber unter realer Last in der Produktion zusammenbricht. Wenn Operations nach einem Sprint ein Performance-Problem anspricht und die Daten bereits in den Logs vorhanden sind, ist die reife Reaktion, dieses Anliegen ins Refinement einzubringen, Performance-Schwellenwerte zur DoD hinzuzufügen und Backlog-Items zu erstellen, um die Lücke zu schließen – anstatt es als „nicht im Scope“ abzutun.

MVP, Release-Planung und inkrementelle Lieferung

Das Minimum Viable Product (MVP) ist der kleinste zusammenhängende Teil, mit dem das Team eine Schlüsselannahme mit echten Benutzern testen kann. Sein Zweck ist das Lernen, nicht nur die Lieferung. Die Release-Planung baut darauf auf: Auf Basis einer Roadmap, die aus einem MVP und nachfolgenden inkrementellen Releases besteht, prognostiziert das Team, welche Fähigkeiten in welchem Release landen, wobei die Velocity als grober Richtwert dient.

Die inkrementelle Lieferung verschafft der Organisation Optionalität – die Fähigkeit, die Richtung auf der Grundlage von Fakten statt Meinungen zu ändern. Auf ein „vollständiges“ Release zu warten, bevor man den Benutzern etwas zeigt, ist das Anti-Pattern, das durch agile Methoden gezielt verhindert werden soll.

← Teamführung · Alle Domänen · Umfang →

Diese Fragen üben → · Zeitlich begrenzte Übung auf ExamRoll.io →