Warum? Was ist das Problem?

Als Dienstleister mit vielen Projekten ist es nicht ungewöhnlich, dass sich Teamkonstellationen ändern. Das kann viele Gründe haben: Manchmal gehen Projekte zu Ende, manchmal möchten Menschen sich einfach weiterentwickeln und Neues lernen, und manchmal müssen wir auf unvorhergesehene Änderungen reagieren. Wenn neue Teammitglieder ins Team stoßen, beginnt das Verständnis der Komplexität einer User Story zu variieren, was zu langen Diskussionen führen kann. In vielen Fällen geht es bei diesen Diskussionen um die richtige Anzahl von Story Points – vielleicht habt ihr das schon gehört: „Für mich ist das eher eine 13″ oder „Ich würde sagen, das ist eher eine 21″ und so weiter. Das passiert, weil die Zahlen nicht das Verständnis jemandes von Komplexität widerspiegeln – und genau hier kommen Referenzstories ins Spiel.

Was sind Referenzstories?

Referenzstories sind bereits geschätzte und implementierte User Stories, die als Referenz dienen, wenn Diskussionen in eurem Backlog Refinement unproduktiv zu werden drohen. Sie werden von den Teammitgliedern gemeinsam in einem Spiel erarbeitet, das ich euch gleich erklären werde. Referenzstories schaffen ein gemeinsames Verständnis der Korrelation zwischen Schätzung und Komplexität. In unserem Fall hat jede Fibonacci-Zahl eine ihr zugeordnete Referenzstory, auf die wir uns beziehen können, wenn wir uns nicht auf eine Schätzung einigen können.

Aktion: Lasst uns unsere Referenzstories finden!

Einige Voraussetzungen für das Spiel:

  • Wählt 15 bis 30 User Stories aus und stellt sicher, dass sie unterschiedliche Schätzungen haben. Ich habe eine einfache Jira-Abfrage verwendet, die meine Stories nach Status und Story Points gefiltert hat.
  • Die Stories, die ihr als Kandidaten auswählt, sollten bereits implementiert und im Status „Fertig” sein. Das stellt sicher, dass ihr wisst, wie viel Aufwand ihr tatsächlich hattet.
  • Wenn möglich: Versucht, Stories zu sammeln, an deren ursprünglicher Schätzung die meisten Teammitglieder beteiligt waren – die Stories sollten nicht zu alt sein. Dadurch habt ihr eine höhere Chance, die Story korrekt zu interpretieren.
  • Ihr werdet den neuen Wert nicht mit dem alten vergleichen. Betrachtet es als eine Neukalibrierung eurer Schätzung.

Probiert unsere Referenzstories-Vorlage in Miro aus.

Teil I – Die Stories horizontal sortieren

Wir haben jetzt einen Stapel User Stories mit unterschiedlichen Schätzungen, und unser Ziel in Teil I ist es, sie horizontal von klein nach groß zu sortieren. In diesem Stadium spielt es keine Rolle, ob eine Story definitiv größer ist als eine andere. Ihr müsst noch nicht zu präzise sein – wir werden sie in der nächsten Runde schärfen. Wichtig ist, dass wir eine horizontale Reihenfolge mit unseren User Stories etabliert haben und einen Konsens darüber erzielt haben.

A blue rectangle features eight evenly spaced yellow rectangles in a row, with small in the top left and big in the top right, reminiscent of visual cues often used in Reference Stories. Three translucent circles overlap the background.

Teil II – Die Stories schätzen

Der nächste Schritt ist die Diskussion jeder Story von links nach rechts, und unser Ziel ist es, ihnen Fibonacci-Zahlen zuzuweisen. Eine gute Möglichkeit dazu ist das Erstellen von Kategorien/Buckets. Beachtet, dass ihr die Story nicht so schätzen müsst, wie ihr es in eurem Backlog Refinement tun würdet – das habt ihr bereits getan. Es ist wichtiger, die richtige Kategorie/den richtigen Bucket für jede Story zu finden. Stories pro Kategorie/Bucket müssen nicht notwendigerweise gleich groß sein, sind aber irgendwie vergleichbar. Beginnt mit der kleinsten Story, schlagt eine Kategorie vor und diskutiert die Entscheidung mit euren Teammitgliedern. Die kleinste Story auf der linken Seite muss nicht unbedingt eine „1″ sein – sie könnte eine „2″ oder sogar eine „3″ sein. Das hängt von der Story ab, die ihr für dieses Spiel gewählt habt. Nachdem ihr die erste Story geschätzt habt, legt den Zettel in die richtige Kategorie/den richtigen Bucket und geht zur zweiten über, diskutiert sie und bewegt euch zur nächsten. Versucht, nicht auf den ursprünglich geschätzten Wert zurückzublicken, und konzentriert euch darauf, die Diskussion von Grund auf neu zu führen, gemeinsam in eurer aktuellen Teamkonstellation. Das ist wichtig, um unser Gesamtziel zu erfüllen: ein gemeinsames Verständnis von Komplexität zu haben. Ihr könntet auf intensivere Diskussionen über die Schätzungen stoßen, aber das ist in Ordnung – findet eine Einigung in eurem Team. Nachdem ihr alle Stories geschätzt habt, sollte euer Board etwa so aussehen:

A row of seven yellow sticky notes numbered 1 to 13, arranged left to right on a bright blue background labeled small on the left and big on the right, with faint circular patterns in the background—perfect for illustrating Reference Stories in a visual and organized way.

Teil III – Eure Referenzstory auswählen

Herzlichen Glückwunsch! Ihr habt alle eure Referenzstories einer Schätzung zugeordnet. Jetzt gibt es noch einen letzten Schritt. Das Ziel von Teil III ist es, sich für eine User Story pro Fibonacci-Zahl zu entscheiden. Diese Referenzstories sollen euch helfen, wenn ihr in eurem Refinement-Meeting keine Einigung erzielen könnt. Um den Raum für weitere Diskussionen und Unsicherheit zu verringern, empfehle ich, nur eine Story pro Schätzung verfügbar zu haben. Wählt also in Runde III die aus, für die ihr euch entscheiden möchtet.

A blue rectangle with small to big labels on opposite corners evokes the concept of Reference Stories. Six numbered squares (1, 1, 2, 3, 5, 8) sit above yellow rectangles, while light blue circles are scattered in the background.

Und dann?

In Zukunft möchtet ihr auf die Referenzstories eures Teams zurückgreifen, wenn ihr Probleme in eurem Refinement-Meeting habt – also dokumentiert sie irgendwo in eurem Projektbereich. Ihr werdet sehen: Je länger eure Teammitglieder zusammenarbeiten, desto besser wird ihr gemeinsames Verständnis. Wenn euer Team angepasst wird, wiederholt das Spiel und schafft erneut gemeinsames Verständnis.

Fazit für CLF

Im letzten Monat ist unser Team um fünf Personen gewachsen, und die Referenzstories haben uns dabei geholfen, ein gemeinsames Verständnis davon zu schaffen, wie wir Komplexität schätzen. Ich habe mich entschieden, diese Methode anzuwenden, um auf langwierige Diskussionen in unseren Refinements zu reagieren, die sich als unproduktiv erwiesen hatten. Es ist wichtig zu beachten, dass Referenzstories nicht alle eure Diskussionen beseitigen – und das sollten sie auch nicht! Wir leben in einer schnelllebigen Welt, und IT-Dienste sind beliebter denn je. Teamwechsel werden in der Zukunft stattfinden. Mein nächster Schritt ist es, das Wort in unserem Unternehmen direkt an unsere Projektleitungen weiterzugeben, eine gemeinsame Praxis zu etablieren und diese bei Bedarf anzupassen. Ich hoffe, das hat geholfen – und wenn ihr Fragen oder Anregungen habt, lasst es mich wissen!