Stille Backlog-Refinement-Meetings: ein effektiveres Agile-Meeting

Ich zeige euch kurz, wie ihr sie in eurer Organisation umsetzen könnt.

Aber zunächst:

Backlog Refinement ist an sich schon eine Herausforderung

Euren Backlog zu verfeinern, ist eine Wissenschaft für sich. Dabei gibt es viele Herausforderungen, zum Beispiel:

• Wie ihr alle einbezieht

• Wie ihr euch optimal vorbereitet

• Wie ihr produktive Diskussionen führt und das gesamte Team dazu bringt, während des Meetings wertvollen Input zu geben

• Wie ihr all das effizient umsetzt, ohne zu viel Zeit von der „eigentlichen“ Arbeit abzuziehen

Remote-Meetings bringen zusätzliche Herausforderungen mit sich

Online-Meetings haben die Situation noch schwieriger gemacht. In Online-Meetings ist effiziente Kommunikation schwierig. Eine Person spricht, die anderen hören (vielleicht) zu – oder machen vielleicht etwas anderes. Oft reden bestimmte Personen (ihr wisst, wen wir meinen) viel zu lange weiter, weil ihnen die visuellen Signale der anderen fehlen, dass es Zeit ist, zum nächsten Punkt überzugehen.

Stille Meetings – eine einfache Methode, um diese Herausforderungen zu lösen

Stille Meetings haben sich entwickelt, um die Probleme traditioneller Meetings zu lösen. In einem stillen Meeting konzentriert ihr euch stärker darauf, Material zu lesen, darüber nachzudenken und es zu kommentieren, das vor dem Meeting vorbereitet wurde.

Denn Lesen ist:

• eine deutlich schnellere Form der Kommunikation als Sprechen und Zuhören.

• viel demokratischer – Introvertierte oder Nicht-Muttersprachler werden nicht so leicht von wortstarken Extrovertierten dominiert.

Damit eignet sich die Methode der stillen Meetings perfekt für Backlog Refinement. Entwickler sind es gewohnt, zu lesen und zu kommentieren. Und es gibt viele introvertierte Entwickler.

Mehr über Backlog-Management erfahren

• Die Lösung für euren zu großen Backlog: eine Produkt-Wunschliste

• 3 Refinement-Praktiken für einen gesünderen, planbaren Backlog

• So verfeinert ihr euren Backlog effizienter – durch disziplinierte Vorbereitung

• Kanban für schnelleres und besseres Backlog Refinement nutzen

Was stille Backlog-Refinement-Meetings sind

Sehen wir uns zunächst die Grundlagen stiller Meetings an. Anschließend schauen wir uns an, wie ihr sie speziell auf Backlog-Refinement-Meetings anwenden könnt.

Stille Meetings bestehen aus:

1. Agenda (Ziele und Nicht-Ziele des Meetings, Ablauf und Moderator)

2. Table Read

3. Lesen und Kommentieren

4. Zusammenfassung durch den Moderator, Schlussfolgerungen oder eine Zusammenfassung

Stille Meetings müssen nicht völlig still sein – eher zu 95 %. Teilnehmer können weiterhin sprechen, wenn es nötig ist. Der Großteil der Kommunikation im Meeting erfolgt jedoch durch Lesen, Kommentieren und Ergänzen des Arbeitselements, das ihr gemeinsam erstellt.

Der Table Read

Stille Meetings funktionieren nur, wenn es einen Ausgangspunkt gibt. Ein traditionelles Meeting beginnt möglicherweise mit einer PowerPoint-Präsentation. Stille Meetings sollten stattdessen mit einem Table Read beginnen. Der Table Read ist eine schriftliche Darstellung. Das Manifest für stille Meetings empfiehlt eine Darstellung von 4 bis 6 Seiten.

Den Table Read für stille Backlog-Refinements nutzen

Der Table Read für das Refinement könnte eine User Story sein, die vom Product Owner oder einem anderen Teammitglied vorbereitet wurde.

Die Story hätte weiterhin:

• Titel

• Beschreibung der Story

• Zusätzliche Informationen

• Akzeptanzkriterien (diese sind wichtig – mehr dazu hier)

Ihr könnt auch eine Darstellung ergänzen, sie ist jedoch nicht zwingend erforderlich. Ihr könnt stille Refinements sogar nutzen, um Epics oder Initiativen zu analysieren. In diesen Fällen ist eine längere schriftliche Darstellung umso sinnvoller.

Der Prozess für stille Backlog-Refinements

Nutzt ein Tool, mit dem jeder Teilnehmer die Beiträge anderer sofort sehen kann. Jira eignet sich dafür nicht besonders gut. Bessere Optionen sind Confluence (im gemeinsamen Bearbeitungsmodus), Miro-Boards oder ähnliche Online-Whiteboard-Tools.

Ihr führt jedoch kein Kloster. In einigen Teilen der Diskussion müsst ihr möglicherweise sprechen. Manche Fragen oder Kommentare sind zu komplex, um sie aufzuschreiben. Dennoch sollte das Team dem Sprechen möglichst widerstehen und Schreiben und Lesen bevorzugen.

Vor der stillen Session sollte das Team Folgendes vereinbaren:

• Welches Tool verwendet wird.

• Ein Schreibformat, um zusätzliche Erläuterungen, Kommentare und Fragen zur Story hinzuzufügen.

• Wie ihr etwas kennzeichnet: Wie ihr Zustimmung oder Ablehnung zu geschriebenen Inhalten ausdrückt, etwa mit Daumen hoch, Sternen am Zeilenende oder Ähnlichem.

• Wie das Team signalisiert, dass es bereit ist, zur Aufwandsschätzung überzugehen. Das kann eine Timebox sein (5 Minuten pro Element) oder der Moderator stellt fest, dass keine weiteren Änderungen erfolgen.

• Wie ihr den Aufwand für ein Element schätzt, zum Beispiel mit einem speziellen Tool, einem Miro-Board-Add-on oder einer gleichzeitigen Abstimmung im Chat.

Hier ist mein Vorschlag für die Kennzeichnung:

• Nicht verstanden – Fragezeichen: „?“

• Gefällt mir, unterstütze ich, stimme voll zu – Stern: „*“

• Stimme überhaupt nicht zu – Ausrufezeichen: „!“

So führt ihr ein stilles Backlog Refinement durch

Vor dem Meeting

1. Der Product Owner sammelt die zu verfeinernden Stories in dem Tool, das ihr verwendet.

2. Die Stories werden vorab von jemandem vorbereitet (Table Read) (siehe hier, warum das so wichtig ist).

Im Meeting

1. Vom Facilitator gesteuert liest das Team die Story-Beschreibung nacheinander und still durch.

2. Das Team bearbeitet und kommentiert die Story, stellt Fragen und stimmt dem jeweiligen Thema zu oder nicht zu.

3. Der Facilitator stellt fest, dass die Bearbeitung langsamer wird (oder ein vereinbartes Timebox-Limit erreicht ist).

4. Das Team schätzt den Aufwand, zum Beispiel mit Planning Poker.

5. Ihr geht zum nächsten Punkt auf der Agenda über.

Kurz gesagt: Warum die Methode des stillen Meetings perfekt für Backlog Refinement ist

Diese Art des Backlog Refinements ist nicht nur deutlich schneller und effizienter:

• Sie zwingt das Team dazu, die Backlog-Items für das Refinement vorzubereiten (damit der Table Read stattfinden kann).

• Sie dokumentiert die Refinement-Diskussion automatisch im Item.

• Sie ist eine deutlich demokratischere Art der Diskussion und ermöglicht es weniger wortstarken und weniger erfahrenen Teammitgliedern, ihre Meinung freier zu äußern.

Ich sage nicht, dass diese Praxis für jeden und jedes Team geeignet ist. Aber probiert sie aus, experimentiert damit oder mit einzelnen Bestandteilen und macht euch selbst ein Bild.