Wie ihr eure Agile-Zeremonien verbessert

Das Team riskiert, Backlog-Items mit unklaren Beschreibungen in das Sprint Backlog aufzunehmen. Das führt zu einer langsamen Umsetzung sowie später zu mehr Fehlern und Änderungen. Das Backlog wird nicht priorisiert und nicht von überflüssigen Stories bereinigt. Es ist schwierig, den Aufwand zu schätzen oder Arbeiten über den nächsten Sprint hinaus vorzubereiten.

Regelmäßige Refinement-Sitzungen schaffen Klarheit über die Backlog-Elemente. Der Product Owner kann Backlog-Elemente sowohl während als auch außerhalb der Refinement-Sitzung besser priorisieren. Beim Refinement stehen Elemente für den nächsten Sprint und die Zeit kurz danach im Fokus.

Das Team nutzt die „Definition of Ready“ aktiv. Es gibt Größenlimits, die dabei helfen, Elemente sinnvoll aufzuteilen. Komplexe Elemente werden im Backlog identifiziert und außerhalb der Refinement-Session separat vorbereitet. Die Maßnahmen im Refinement konzentrieren sich auf die nächsten ein bis zwei Monate des Backlogs.

Der Backlog wird regelmäßig bereinigt. Das Team nutzt aktiv verschiedene Methoden zum Aufteilen sowie das INVEST-Modell für User Stories. Gemeinsame Refinement-Sessions mit anderen abhängigen Teams werden organisiert. Die Refinement-Aktivitäten gehen über die nächsten ein bis zwei Monate im Backlog hinaus und reichen als grobes Refinement bis zu zwölf Monate weit.

Es kommt selten vor, dass ein Scrum-Team kein Sprint Planning durchführt. Wenn doch, gibt es wahrscheinlich keine Sprints – das bedeutet, dass das Team reines Kanban nutzt.

Der Product Owner bringt einen Vorschlag für die Inhalte des Sprints in das Planning-Meeting ein. Auch die obersten Einträge im Product Backlog sind priorisiert, sodass Änderungen an diesem Vorschlag möglich sind. Das Team kann die Inhalte des Sprints abhängig von seiner Velocity verhandeln und anpassen. Möglicherweise kommen auch Stretch Goals zum Einsatz. Die Definition of Done ist dokumentiert und wird angewendet.

Sprint-Ziele sind definiert. Die „Definition of Ready“ dient als letzte Kontrollinstanz, um Inhalte in das Sprint Backlog aufzunehmen. Die Sprint-Simulation hilft dabei, die Auslastung auszubalancieren und die Sprint-Inhalte auf Plausibilität zu prüfen. Kundenbedarf und Akzeptanzkriterien werden für alle Einträge aktiv besprochen.

Die Planung der Demo beginnt im Sprint Planning. Elemente mit hohem Risiko sowie Elemente, die während des Sprints eine Validierung der Ausrichtung erfordern, werden identifiziert. Während des Events behalten alle das große Ganze und die Vision im Blick – mit einer groben Ausarbeitung über einen Zeitraum von bis zu zwölf Monaten.

Das Team erreicht die Sprint-Ziele nicht effektiv und wird Schwierigkeiten haben, die wichtigsten Punkte aus dem Sprint Backlog umzusetzen. Hilfsangebote oder Bitten um Unterstützung werden oft ignoriert, und die Teammitglieder arbeiten stärker isoliert voneinander. Selbstorganisierte Zusammenarbeit fällt schwer.

Das Daily findet mehrmals pro Woche statt und dauert höchstens 15 Minuten. Das Grundformat lautet: Gestern, Heute und Hindernisse.

Das Daily wird vom Team selbst gestaltet, nicht vom Scrum Master. Der Scrum Master beobachtet. Erkenntnisse werden bei Bedarf geteilt. Die Teammitglieder sehen, wann ihre aktuelle Aufgabe endet, und besprechen das optimale nächste Backlog-Element. Momente wie „Gut, dass wir dieses Meeting hatten“ sind keine Seltenheit. Das Daily führt dazu, dass Teammitglieder sich aktiv gegenseitig unterstützen.

Das Team übernimmt die volle Verantwortung für das Daily und betrachtet die Fortschritte auf dem Weg zu den Sprint-Zielen. Erledigte Aufgaben werden gefeiert! Das Daily hilft dabei, Hindernisse zu lösen, und Teammitglieder, die feststecken, erhalten Unterstützung – auch wenn sie nicht darum gebeten haben.

Das Team erfährt nicht, warum bestimmte Aufgaben erledigt wurden und andere nicht. Der Gesamtüberblick (Zeitplan, Fristen, Budget) bleibt unbekannt.

Die Fertigstellung der Aufgaben wird überprüft. Nicht abgeschlossene Aufgaben werden in den nächsten Sprint verschoben.

Der Product Owner nimmt die Ergebnisse ab. Erledigte Arbeitspakete werden regelmäßig anhand der „Definition of Done“ überprüft. Das Team analysiert, warum einige Arbeitspakete nicht abgeschlossen wurden. Erkenntnisse aus dem Sprint werden umgesetzt und das Backlog angepasst. Unterstützung anderer Teammitglieder.

Der Product Owner kann Elemente während des Sprints freigeben. Das Team berücksichtigt die Auswirkungen des Sprints auf das große Ganze, und Risiken sowie Maßnahmen zur Risikominimierung werden aktiv überprüft. Berichte an Stakeholder werden berücksichtigt.

Die Verbesserung der Arbeitsweisen geht nur langsam oder gar nicht voran. Die Teamleistung verharrt auf einem bestimmten Niveau.

Regelmäßige Retrospektiven finden statt und führen zu Diskussionen, der Identifizierung von Verbesserungsmöglichkeiten und Maßnahmen. Für jede Maßnahme wird ein Verantwortlicher festgelegt.

Die Zeit im Meeting wird so genutzt, dass eine gute Ursachenanalyse und Aktionsplanung möglich sind. Frühere Maßnahmen werden nachverfolgt. Maßnahmen können ins Sprint Backlog aufgenommen werden, damit das Team die „Erlaubnis“ hat, sofort daran zu arbeiten. Es werden verschiedene Retrospektivmethoden ausprobiert und eingesetzt. Manchmal hat die Retrospektive ein bestimmtes Thema.

Retrospektiven werden genutzt, um alle Agile-Zeremonien regelmäßig zu verbessern. Sie werden nicht immer von derselben Person moderiert und finden manchmal gemeinsam mit anderen Teams statt, um die Zusammenarbeit im Programm oder in der Organisation zu verbessern. Futurespective-Methoden werden regelmäßig eingesetzt. Das Team erweitert seinen Einfluss über das eigene Team hinaus.

• Zu Beginn des Sprints findet ein separates Sprint-Planungsmeeting statt

• Die obersten Einträge im Backlog wurden vom Product Owner vorab priorisiert

• Das Team wählt Einträge aus dem oberen Bereich des Backlogs aus, bis es genug Arbeit für den Sprint ausgewählt hat

• Das Team erstellt Aufgaben für die Einträge, mit denen es beginnen möchte

• Das Team kann für den Sprint Stretch Goals festlegen

• Die Definition of Done ist dokumentiert, wird vom Team verstanden und aktiv genutzt

• Nur Einträge, die die Definition of Ready des Teams erfüllen, werden für das Sprint Backlog freigegeben.

• Die meisten für den Sprint ausgewählten Einträge sind vorab verfeinert und erfüllen die DoR.

• Neue Einträge, die die DoR nicht erfüllen, werden im Planning Meeting so lange verfeinert, bis sie die DoR erfüllen.

• Neue Einträge, die die DoR nicht erfüllen, werden im Planning Meeting so lange verfeinert, bis sie die DoR erfüllen.

• Das Team führt eine Sprint-Simulation durch, um die Auslastung auszugleichen und die ersten Tage zu planen.

• Das Team erkennt, wann es sich in vergangenen Sprints zu viel vorgenommen hat, und passt den Umfang des Sprints an.

• Die Diskussion über die ausgewählten Inhalte ist aktiv, insbesondere über Kundenbedürfnisse, Aufwandsschätzung und Akzeptanzkriterien.

• Das Team berücksichtigt Kapazitäten, die von nicht abgeschlossenen Einträgen des vorherigen Sprints beansprucht werden, wenn Team und PO entscheiden, diese im aktuellen Sprint fortzusetzen.

• Das Team berücksichtigt die Auswirkungen von Schulungen, Urlaub usw. auf die Kapazität.

• Das Team nimmt keine Backlog-Einträge, die größer als die Teamgrenze sind, als einzelne Sprint-Backlog-Einträge auf, ohne sie aufzuteilen.

• Das Team verwendet Sprint-Ziele.

• Die Elemente, die am Ende des Sprints potenziell vorgeführt werden, werden in der Sitzung geplant

• Elemente aus dem Sprint-Backlog mit hohem Risiko und hoher Unsicherheit werden identifiziert

• Das Team behält das große Ganze, die Produktvision und die Release-Vision im Blick und berücksichtigt, wie die ausgewählte Arbeit damit zusammenhängt

• Mitglieder übernehmen freiwillig Elemente, die dazu anregen, Neues zu lernen

• Das Team findet eine passende Timebox für die Sprint-Planung

• Das Team kann die Reihenfolge der Umsetzung von Sprint-Backlog-Elementen neu festlegen, um den bestmöglichen Weg zur Erreichung der Sprint-Ziele und zum Abschluss der ausgewählten Aufgaben zu finden

• Das Daily findet mehrmals pro Woche statt und ist auf weniger als 15 Minuten begrenzt

• Was ich gestern gemacht habe, was ich heute machen werde, Probleme

• Das Daily findet jeden Tag statt, auch wenn der Scrum Master nicht dabei ist

• Was habe ich gelernt, das andere unbedingt wissen sollten?

• Wann ist meine aktuelle Aufgabe bereit für den nächsten Schritt?

• Die Teammitglieder hören einander wirklich zu

• Womit wird als Nächstes begonnen? Das Team berücksichtigt die Prioritäten im Sprint Backlog.

• In der Regel gibt es mindestens einen Moment, in dem man denkt: „Gut, dass wir dieses Meeting hatten.“

• Häufige Follow-up-Meetings zu Problemen, die im Stand-up identifiziert wurden

• Feedback wird wahrgenommen und darauf reagiert

• Das Team verantwortet die tägliche Zeremonie (mit oder ohne Scrum Master)

• Das Team berücksichtigt den Fortschritt in Richtung Sprint-Ziel und die Fertigstellung des Sprint-Backlogs

• Feier der Erfolge

• Das Team merkt, wenn jemand feststeckt, spricht es aber nicht offen an

• Hilfsangebote werden wahrgenommen und angenommen

• Das Team kennt die Risiken bei den Einträgen im Sprint-Backlog und weiß, wann es handeln muss

• Retrospektive findet regelmäßig statt

• Die Retrospektive führt zu konkreten Maßnahmen

• Für die Maßnahmen gibt es jeweils einen benannten Verantwortlichen

• Der Product Owner kann teilnehmen, jedoch als normales Teammitglied – nicht in der PO-Rolle

• Aktionspunkte aus vorherigen Retrospektiven werden nachverfolgt

• Aktionspunkte aus Retrospektiven werden als Einträge im Sprint Backlog in den nächsten Sprint übernommen und wie jede andere für den Sprint ausgewählte Story behandelt (DoR, verfeinert, Aufwand geschätzt, Aufgaben definiert)

• Retrospektivmethoden werden gelegentlich ausprobiert und gewechselt

• Unterschiedliche Themen oder Schwerpunkte werden gelegentlich genutzt

• Das Team versteht, auf welche Dinge es Einfluss hat, und einigt sich auf Maßnahmen, die es eigenständig umsetzen kann

• Retrospektiven werden so durchgeführt, dass sie fokussierte Diskussionen, Ursachenanalysen und Maßnahmenplanung ermöglichen

• In fokussierten Retrospektiven werden einzelne Zeremonien gezielt verbessert.

• Die Moderation der Retrospektive wechselt gelegentlich oder wird reihum übernommen.

• Retrospektiven finden auch gemeinsam mit anderen Teams statt.

• Das Team findet Wege, auf Themen außerhalb seines direkten Einflussbereichs einzuwirken, etwa indem es mit gutem Beispiel vorangeht, durch aktive Teilnahme an Communities Einfluss in der Organisation aufbaut oder Dienstwege nutzt.

• Themen aus Retrospektiven, die zu einem „Dauerbrenner“ werden, in Teamabstimmungen aber wenig Zustimmung finden, werden aufgegriffen, um Probleme zu lösen, die nur wenige Teilnehmer stören.

• Das Team nutzt regelmäßig auch „Futurespective“-Methoden wie Pre-Mortems.

• Das Review ist ein eigener Abschnitt oder ein separates Meeting von der Demo

• Abgeschlossene Aufgaben werden geschlossen

• Nicht abgeschlossene Aufgaben werden in den nächsten Sprint oder zurück ins Backlog verschoben

• Product Owner nimmt die in Prüfung befindlichen Elemente ab

• Das Team analysiert „Done“-Elemente: Erfüllen sie die DoD? Erfüllen sie die NFRs?

• Erfüllen sie den Kundenbedarf, wie er derzeit verstanden wird? Wird im Zusammenhang mit diesem Kundenbedarf noch etwas benötigt? (wird dem Backlog hinzugefügt)

• Das potenziell auslieferbare Inkrement prüfen

• Das Team analysiert die unfertigen Elemente, die nicht zum Stretch Goal gehören: Warum wurden sie nicht fertiggestellt? Waren sie blockiert oder hat das Team sich zu viel vorgenommen?

• Das Team bespricht die Erkenntnisse aus dem Sprint: Müssen die Backlog-Prioritäten angepasst werden? Gibt es neue Elemente für das Backlog oder für den Vorschlag zu den Inhalten des nächsten Sprints? Werden einige Elemente im Backlog aufgrund der Erkenntnisse aus diesem Sprint nicht benötigt?

• Der Product Owner kann Arbeit auch während des Sprints freigeben, nicht nur im Review

• Projektrisiken und Maßnahmenpläne zur Risikominderung werden berücksichtigt

• Der Gesamtüberblick über das Projekt, das Budget und der Zeitplan werden überprüft und aktualisiert

• Das Team identifiziert Stakeholder, die zusätzliche Informationen über den Fortschritt benötigen, und findet einen Weg, sie ihnen bereitzustellen

• Die Demo ist ein separater Abschnitt oder Termin und nicht Teil des Sprint Reviews.

• Stakeholder werden eingeladen, an der Demo teilzunehmen.

• Die Demo wird nicht auf dem Rechner eines Entwicklers oder aus einem Branch gezeigt, sondern aus dem eingecheckten Codeline-Branch.

• Das Publikum der Demo erhält die Möglichkeit, Feedback zu geben.

• Der Ablauf der Demo wird im Voraus geplant.

• Es wird eine gemeinsame, leicht verständliche Sprache verwendet.

• Im Team wechseln sich verschiedene Personen bei der Präsentation von Demos ab: PO, Entwickler, Tester, Stakeholder, Kundensupport ...

• Darstellung, wie sich die gezeigte Funktion in das Gesamtbild einfügt

• Die Planung des Demoablaufs und der Inhalte beginnt bereits im Refinement oder in der Sprint-Planung

• Einige Stakeholder-Gruppen erhalten eine andere Demo als andere (z. B. eine Business-Demo alle 1–2 Monate, Sprint-Demos am Ende jedes Sprints)

• Die Demo führt nach dem Feedback zu Diskussionen oder Folgeterminen; der PO dokumentiert die Erkenntnisse

• APIs werden mit Entwicklungs- oder Testtools präsentiert, die auch anderen zur Verfügung stehen

• Kunden oder Stakeholder-Vertreter werden ermutigt, das Feature selbst auszuprobieren.

• Für Stakeholder, die nicht an der Hauptsession teilnehmen können, werden separate Aufzeichnungen oder Demo-Sessions angeboten.

• Die Demo-Session würdigt auch die geleistete Arbeit und die erreichten Ergebnisse. Nach der Demo hat das Team ein Gefühl der Erfüllung.

• Die Meinungen von Stakeholdern sind keine „Botschaft Gottes“, sondern Feedback wie jedes andere. Das Team kann entscheiden, sie nicht als „die eine Wahrheit“ zu betrachten, und sie hinterfragen. Die Demo ist ein Ort der Zusammenarbeit – kein Reporting.