Wie ich meine Backlog Refinement Zeremonien moderiere im Agile Requirements Engineering


SwissQ,

Meine Erfahrung zeigt, dass agile Vorhaben meist wegen mangelhaftem Requirements Engineering scheitern. Requirements Engineering ist für mich nicht bloss im Wasserfall eine Schlüsseldisziplin, sondern auch in agilen Vorhaben. Wenn Requirements Engineering hustet, dann krankt das Backlog Refinement. In diesem Blog demonstriere ich, wie ich mein Backlog Refinement gestalte.

Backlog Refinement – das unbekannte Wesen

Wir alle wollen priorisierte, geschätzte, abgestimmte und entwickelbare User Stories. Es ist die ureigentliche Aufgabe des Product Owners, den Backlog „fit“ zu halten. Doch in meinem Alltag als Consultant begegne ich oft wirren, undurchsichtigen, verschwommenen und vor allem unklaren Backlogs. Merkmale solcher Backlogs sind:

  1. Unklar-uneinheitliche geschnittene User Stories
  2. Stets wechselnde Lösungsdichte
  3. Diffuse bis keine Definition of Ready
  4. Ausufernde Beschreibungen und Word-Anhänge

Und so weiter. Ich frage dann immer: Wie macht ihr Backlog Refinement? Doch diese Frage kann mir niemand schlüssig beantworten. Spätestens am Planning (egal ob I oder II) spüre ich, dass kein gemeinsames Verständnis besteht, was nun zu tun sei. Zu viele Diskussionen an den Planning-Zeremonien ist das deutlichste Symptom, dass Backlog Refinement nicht wirklich klappt.

Am Anfang ist das Bild

Ich durfte schon etliche Backlog Refinement Zeremonien begleiten oder kraft meiner Rolle moderieren und gestalten. Wenn ich Backlog Refinement mache, will ich immer zuerst ein Bild. Worum geht’s? Was ist der Kontext? Warum wollen wir etwas? Bei fortgeschrittenen Projekten darf etwas erweitert werden. Bei noch jungen muss etwas gebaut werden. Also skizzieren wir gemeinsam, was grob zu tun ist und ergründen gemeinsam das Warum.

In der Form dieser Projektdokumentation bin ich totalst leidenschaftslos; mir genügen Papier und Stift. Ich kenne natürlich einige Techniken, die je nach Projektsituation sich eignen und kann damit variieren. Ich „stürme“ solange an diesem Bild, bis wir auf hohem Level ein gemeinsames Verständnis stabilisiert haben. Das kann je nach Projektsituation zehn Minuten bis zwei Stunden dauern. Das, weil wir mir wichtig ist, dass der Product Owner und das Team bereits auf hohem Level gemeinsam verstehen, was sie tun und warum sie etwas tun. Ohne dieses gemeinsame Verständnis sind für mich User Stories sinnlos, weil verständnislos.

Mein Geheimnis ist die Sequence Sketch. Das ist ein sehr grobes Sequenzdiagramm, das die wichtigsten Anforderungen eines Themas zusammenfasst. Diese Methode ist einfach und mächtig zugleich. Auf meinem Twitter-Profil habe ich sie bereits gewürdigt. Sie ist für mich die „ultimative Waffe“ schlechthin.

Sequenzskizze-Ohne-Schnitt

Die Königsdisziplin: Schneiden von User Stories

Sobald das Bild gefestigt ist, schneide ich gemeinsam mit allen Beteiligten die darunterliegenden User Stories, Features oder gar Epics. Ich will damit sicherstellen, dass jedermann versteht, wie wir schneiden. Damit verhindere ich Unklarheiten, wie sich die einzelnen Elemente abgrenzen. Ich zeichne den Schnitt direkt auf meine Sequence Sketch. Das kann mehrere Iterationen dauern, denn neue Erkenntnisse können einen vorherigen Schnitt erübrigen. Auch hier bin agil im strengsten Wortsinn. Ich folge nicht stur einem mal gemachten Schnitt, sondern hinterfrage ihn mit jeder gewonnenen Erkenntnis.

Sequenzskizze-Mit-Schnitt

Und dann: Abtippen!

Haben wir ein gemeinsames Verständnis, gemeinsam geschnitten und das ganze nochmals vor der Skizze rekapituliert, dann haben wir’s fast geschafft. Was nun folgt, ist reiner Fleiss. Die geschnittenen Elemente müssen nun konserviert werden. Eine sinnige Beschreibung im klassischen User Story Template mit zwei-drei Akzeptanzkriterien sowie ein Link auf die vorhin gemalte Skizze müssen und dürfen ausreichen. Mehr beinhaltet die User Story nicht. Alles andere ist Verschwendung.

Die entspannten Planning-Zeremonien

Wer im Backlog Refinement bereits priorisiert und schätzt, der kann sich am Planning zurücklehnen. Wer ein konsequentes Backlog Refinement waltet, muss sich vor keinem Planning mehr fürchten. Das sind Aussichten!

Mehr über Agile RE

Meine fünf Prognosen über Agile Requirements Engineering
Die SwissQ Backlog Management Checkliste
Das SwissQ Agile RE Framework Poster

Weitere Blog lesen

0 thoughts on “Wie ich meine Backlog Refinement Zeremonien moderiere im Agile Requirements Engineering”


Schreibe einen Kommentar