Mal ein paar Gedanken und lesenswerte Artikel zum Thema Product Backlog Refinement in Scrum.

Besonders schön fand ich den Artikel von David Pareira. Er listet ein paar typische, gern auftrende Phänomene auf, die ihr unbedingt vermeiden solltet, um ein ergiebiges Refinement durchzuführen.

What NOT to do during the backlog refinement?
If you’ve worked with Product Backlogs, I guess you have been to at least one Backlog refinement that was a nightmare, meaning that the session led nowhere. The team was disengaged, demotivated, and…
Serious ScrumDavid Pereira

Beispiele von Good Practices im Refinement

Was wären denn nun gute Vorgehensweisen in Refinements?

Im Grunde könnte man schonmal alle oben gelisteten "bad practices" ins Gegenteil verkehren. Besonders hervorheben möchte ich allerdings Drei der gelisteten negativen Beispiele.

  • Do not force what you dont' know
  • Do not accept the word impossible
  • Do not fall into endless technical disussions

Eigentlich recht selbsterklärend, was stattdessen passieren sollte: das Team sollte nicht "abused" werden. Mindestens der Scrum Master – eigentlich ein jeder "Kommunikationsarbeiter" – sollte ein Gespür dafür haben, wann so ein Zeitpunkt ist, an dem Items versucht werden zwanghaft ready zu bekommen. Oft kommt das in Verbindung mit dem letzten Punkt einher. Es wurde nun schon 20 Minuten immer wieder im Kreis diskutiert und dennoch ist das Team nicht wirklich weiter gekommen. Anstatt der Versuchung (oder einem übergriffig werdenden PO oder Team-Mitglied) nachzugeben, "einfach" eine Story-Point Schätzung rein zu schreiben, ist es sinnvoller diesen Zustand zu akzeptieren und eine erreichbare Spike zu erstellen. Akzeptiere und respektiere das Unwissen sozusagen.

Es hat natürlich mit Mut zu tun, diesen Zustand anzuerkennen und den Ausweg der Spike "zuzulassen". An dieser Stelle sei auch nochmal gesagt, dass Spikes eigentlich spärlich eingesetzt werden sollten. Je Komplexer oder neuer das Terrain, auf dem sich ein Team bewegt, desto häufiger kann (und sollte) es erfahrungsgemäß zu Spikes kommen.

Wie passt da aber nun "Do not accept the word impossible" dazu?
Hierbei geht es um eine "Yes we can"-Mentalität. Natürlich alles im fachlich passenden Rahmen. Es kann schonmal vorkommen, dass Teams mit Backlog-Items am Anfang überfordert sind. Die meisten Dinge können allerdings so zerlegt werden, dass sie am Ende doch erreichbar sind. Je länger ein Team zusammen bleibt, desto weniger wird es zu Items dieser Ausrprägung kommen. Entweder sind sie vorher vom PO schon gut genug zerlegt worden, oder das Team merkt im Refinement recht schnell, dass es sich um ein solches Item handelt und schickt den PO zu sezieren; oder es wird ein gemeinsames, dediziertes Meeting für die Weiterbearbeitung des Item ins Leben gerufen.

Ein Refinement Flow / Refinement Vibe erreichen

Meiner Erfahrung nach ist es ein gutes Ziel, mit einem Team ein gewissen Flow in Refinement Meetings zu gelangen.