In meinen bisherigen Scrum-Projekten habe ich das Product Backlog Refinement wie folgt erlebt: Das ganze Team versammelt sich in einem Raum und der PO stellt eine Userstory vor. Das Team stellt solange Fragen, bis (mehr oder minder) alles klar ist. Dann macht man eine Schätzung, z.B. mit Planning Poker-Karten und schreitet zur nächsten Story vor.

Aufgrund der Grösse meines aktuellen Teams kam diese Form nicht mehr in Frage. Denn Meetings mit vielen Personen neigen dazu, dass sich einige langweilen und nicht mehr aktiv teilnehmen. Weiter habe ich in solchen Refinements endlose Diskussionen erlebt, wie genau eine Story jetzt definiert werden muss. Die einen wollen es halt detailliert, die anderen sehen es eher pragmatisch. Also musste eine neue Form des Refinements her, welche auch mit grösseren Gruppen effizient funktioniert.

Vor-Refinement

Neben dem eigentlichen Entwicklerteam habe ich zwei Business-Analysten, zwei Fachvertreter und einen Tester. Diese bereiten die rohen Userstories vor, welche zu Beginn kaum mehr als eine Überschrift haben. Im Vor-Refinement wird also der eigentliche Inhalt sowie die Akzeptanzkriterien definiert. Hier werden Abklärungen mit Umsystemen und Stakeholder getroffen.

Diese Vorarbeiten laufen in einem kleinen Kanban-Modus und die Stories durchlaufen drei Stadien:

• Todo: Eintrittspunkt für neue User-Stories. Hier ist praktisch nur der Titel bekannt.
• Preperation in Progress: Es werden Aufgaben geschrieben, welche pro Story gemacht werden müssen. Dies sind typischerweise Analyse-Aufgaben und Abklärungen.
• Ready for Refinement: Wenn alle Fragen geklärt sind ist die Userstory parat, um vom Entwicklerteam angeschaut zu werden.

Zweimal pro Woche stehen die Business-Analysten, Fachvertreter und Tester vor dem Board zusammen und besprechen den aktuellen Stand.

Refinement

Das eigentliche Refinement findet jede Woche statt und dauert etwa 75 Minuten. Trotz unseres Grossraumbüros haben wir ein eigene Team-Zone, wo wir recht ungestört arbeiten können. Deshalb können wir für das Refinement auf ein Sitzungszimmer verzichten und uns gleich bei den Arbeitsplätzen treffen. Eingeladen ist das ganze Team mit Entwickler, BA, Fachvertreter und Tester.

Intro

Die Teilnehmer aus dem Vor-Refinement stellen kurz die Stories vor, welche auf dem Kanban-Board neu in der Spalte Ready for Refinement stehen. Und mit „kurz“ meine ich wirklich nur ein paar Sätze. Das Entwicklerteam braucht nur eine grobe Vorstellung, um was es geht, mehr nicht. So dauert das Intro meist nur fünf Minuten.

Refinement nach dem Pull-Prinzip

Jetzt teilt sich das Entwicklerteam selbstorganisiert in Gruppen mit zwei oder drei Personen drauf und schnappen sich eine Story vom Board. Wie die Gruppen diese Story jetzt bearbeite ist ihnen überlassen. Die Fachvertreter und Business-Analysten befinden sich im selben Raum und stehen für Rückfragen zur Verfügung. Sie drängen sich den einzelnen Team aber nicht auf. Nur so ist sichergestellt, dass die Beschreibungen im Jira am Schluss wirklich auch verstanden sind.
Wenn Fragen auftauchen, welche nicht gleich vor Ort beantwortet werden können, werden diese im Jira-Issue hinterlegt und mit einem Stichwort auf einem Post-it festgehalten. Dieses Post-it wird dann wieder auf dem Kanban-Board in die Spalte Refinement in Progress, offene Fragen gehängt. Diese Fragen müssen bis nächste Woche geklärt werden.

Wenn eine Story fertig bearbeitet wurde kann sich das Team die nächste vom Board nehmen. Dieser Teil des Refinements dauert 45 Minuten. Mittels einer grossen Uhr stellen wir sicher, dass die Timebox eingehalten wird.

Resultate vorstellen und schätzen

Nach 45 Minuten versammeln sich alle wieder vor dem Board. Die einzelnen Team stellen kurz ihre Erkenntnisse vor und erläutern, welche Fragen aufgetaucht sind. So sind alle auf dem aktuellen Stand und eine Story kann nächste Woche auch von anderen Personen bearbeitet werden.
Wenn zu einer Story alle Fragen geklärt sind schreiten wir gleich zu Schätzung vor. Die Gruppe hat sich vorher schon Gedanken gemacht, wie viele Story-Points dafür anfallen. Mit dieser Begründung wird die Story auf ein separates Schätzboard gehängt. Das Plenum ist jetzt aufgefordert, die Schätzung zu hinterfragen und ihre eigene Meinung einzubringen. Wenn sich alle darüber einig sind gilt die Story als parat für die Umsetzung.
Sollten Fragen offen sein, die für die Umsetzung nicht kritisch und für die Schätzung irrelevant sind, werden diese am Board vermerkt und zeitnah geklärt.

Nächste Runde

Die offenen Fragen werden innerhalb der nächsten sieben Tage geklärt und am Vor-Refinement-Standup besprochen. Beim nächsten Refinement werden zuerst die Stories bearbeitet, wo noch offen (und inzwischen hoffentlich geklärte) Fragen vorhanden sind. So stellen wir sicher, dass die Stories möglichst bald mit der Schätzung abgeschlossen werden können und wir uns nicht endlos im Kreis drehen.

Fazit

Diese Art von Refinement habe ich jetzt zweimal mit meinem Team durchgeführt und sehr positives Feedback erhalten. Folgende Vorteile wurden in der Praxis sichtbar:

• Da der PO die Story nicht vorstellt, müssen die Entwickler sich selbst aktiv mit dem Inhalt auseinander setzten. Dadurch werden Unklarheiten und Widersprüche viel schneller sichtbar.
• Gerade in meinem grossen Team gibt es eine sehr gut Durchmischung innerhalb des Entwicklerteam. Man schaut so auch mal eine Story an, welche nicht zu seiner eigenen Kernkompetenz gehört. Obwohl wir in kleinen Gruppen arbeiten verbreitet sich so das Wissen.
• Die Timebox von 45 Minuten hat sich sehr bewährt. Während dieser Zeit kann man konzentriert an einer oder mehreren Stories arbeiten. Ich bin überzeugt, dass wir so effizienter sind, als wenn das ganze Team nach dem herkömmlichen Vorgehen zwei Stunden in einem Sitzungszimmer sitzt und gemeinsam alles durchkaut.
• Ich bin ein grosser Skeptiker von „Selbstorganisiertem Verhalten“. Aber hier hat es sehr gut funktioniert. Mir als Scrum Master blieb wirklich nur noch die Moderation; endlose Diskussionen oder gelangweilte Mitarbeiter gab es keine. Perfekt.