Was ist Product Backlog Refinement?

Das erste, was vielen in den Sinn kommt, wenn das Stichwort Backlog Refinement fällt, ist natürlich das Schätzen von User Stories mit Hilfe von Story Points bzw. Planning Poker. Das ist auch alles vollkommen richtig. Allerdings existieren darüber hinaus noch jede Menge weiterer Dinge, die Teil Eures Refinements sein können (und sollten).

Das Backlog Refinement ist also salopp formuliert so etwas wie Unkraut zu jäten. Wenn Ihr es nicht regelmäßig macht, dann wuchert Euer Product Backlog irgendwann zu und Ihr verliert die Übersicht darüber, was zu tun ist und wieviel Aufwand es (wahrscheinlich) sein wird.

Vielleicht fragst Du Dich an dieser Stelle, worauf Ihr Euch bei Eurem Refinement am besten konzentrieren solltet. Nun, die Priorisierung Eures Product Backlogs ist dabei eine große Hilfe für Euch. Denn je weiter unten sich ein Thema im Product Backlog befindet, desto weniger wichtig und dringend ist es ja. Diese Aufgaben dürfen also unklarer und unschärfer sein und benötigen nicht so viel Details wie diejenigen, die sich sehr weit oben befinden.

Gestaltet Euer Backlog Refinement deshalb so, dass Ihr immer ausreichend Klarheit über die nächsten ein bis zwei, maximal drei Sprints erzeugt.

Themen, die sich weiter unten im Product Backlog befinden, können natürlich kurz besprochen werden, aber es reicht vollkommen aus, sie mit ein paar Notizen und einer groben Schätzung zu versehen.

Bis zum Update im November 2020 gab es hierzu eine konkrete Angabe im Scrum Guide. Und zwar sollte die Zeit, die ein Team in das Backlog Refinement investiert, 10 % der gesamten Kapazität nicht überschreiten. Das bedeutet, dass pro Sprint nicht mehr als 4h Zeit in das gemeinsame Refinement fließen sollten, wenn wir von einer 40-Stunden-Arbeitswoche ausgehen.

Mit dem letzten Update ist diese Information jedoch verschwunden. Nichtsdestotrotz stellt sie immer noch eine gute Richtlinie für jedes Scrum Team dar. Ihr solltet Euch jedoch nicht sklavisch daran halten.

Wenn die nächsten ein bis drei Sprints ausreichend gut refined sind und es keine Themen gibt, kann das Backlog Refinement auch ganz entfallen. Umgekehrt ergibt es keinen Sinn, nach 4 Stunden mit dem Refinement aufzuhören, wenn es noch wichtige und dringende Themen zu besprechen gibt.

Wie Ihr Eure Refinement-Termine genau handhabt steht Euch natürlich vollkommen frei. Manche Teams bevorzugen spontane Refinements, die sie nach Bedarf planen. Die meisten legen jedoch feste Serientermine an, damit sie nicht unter den Tisch fallen. Ich persönlich empfehle Dir die letzte Variante, da erfahrungsgemäß immer andere Themen dazwischenfunken, wenn Ihr keine festen Termine habt.

Außerdem solltet Ihr den Termin für Euer Backlog Refinement nicht zu lang ansetzen. Das Meeting kann mitunter sehr anstrengend werden und bei den meisten Scrum Teams ist die Luft nach 2h ohnehin raus.

Es lohnt sich deshalb, pro Woche zwei Refinement-Termine von je 2h Dauer einzuplanen.

Im besten Fall nimmt stets das gesamte Scrum Team am Backlog Refinement teil.

Im Scrum Framework ist das Refinement eine optionale Tätigkeit. Es besteht also keine Pflicht, ein gemeinsames Product Backlog Refinement durchzuführen.

Trotzdem ist Backlog Refinement sehr sinnvoll und ich rate Dir deshalb dringend, es kontinuierlich durchzuführen.

Anders ist es hingegen, wenn Dein Scrum Team Teil eines Nexus ist. Im Nexus Framework gibt es neben den teaminternen Backlog Refinements ein sogenanntes Cross-Team Refinement. Das Cross-Team Refinement ist verpflichtend und beantwortet zwei wichtige Fragen:

Viele Scrum Teams verlieren sich häufig im Detail und betreiben ihr Backlog Refinement hauptsächlich auf der Ebene von User Stories.

Wenn Ihr Euch mit neuen Themen beschäftigt, solltet Ihr daher stets auf Feature-Ebene beginnen. (Oder sogar auf Ebene von Epics.)

Es kann sehr hilfreich sein, Features zunächst in mehrere kleinere Features zu splitten und diese mit T-Shirt-Größen zu schätzen, bevor Ihr damit beginnt, über User Stories zu sprechen. Auf diese Weise könnt Ihr dann später das erste Feature mit User Stories versehen und alle anderen Features erst einmal unbeachtet lassen.

Der zweite Vorteil besteht darin, dass es Euch so auch leichter fallen wird, ein Sprintziel zu formulieren. Dieses besteht dann nämlich darin, ein (kleines) Feature umzusetzen.

Achtet auch darauf, Euch so wenig wie möglich mit der konkreten Umsetzung zu beschäftigen. Im Refinement geht es (vorrangig) um das WAS einer Aufgabe und nicht (so sehr) um das WIE.

Viele Scrum Teams führen das Backlog Refinements nur mit „ausgewählten Teammitgliedern“ durch. Meistens versuchen sie so, andere Kollegen nicht von der Arbeit abzuhalten und besonders effizient zu sein.

Wenn Du Scrum Master bist, sollte das ein Alarmzeichen für Dich sein. Denn es ist ein Hinweis darauf, dass Dein Team nicht kollaborativ arbeitet, sondern jedes Teammitglied während des Sprints seine eigenen Aufgaben erledigt. Fällt der Kollege dann aus (beispielsweise weil er krank wird), bleibt seine Aufgabe in der Regel liegen, weil niemand weiß, worum es geht.

Damit stellt das Refinement in Scrum auch einen zentralen Ort des Wissensaustausches und Lernens dar. Durch ein gemeinsames Refinement können sich Teammitglieder mit neuen Themen beschäftigen, einen tieferen Einblick in das Produkt erhalten und dergleichen mehr.

Ein weiteres Problem, das sehr häufig zu beobachten ist, entsteht durch das falsche Splitten von User Storys (oder Features). Die neu entstandenen User Stories sind zwar kleiner und können gut innerhalb eines einzigen Sprints umgesetzt werden, stiften aber für sich genommen keinen Nutzen.

Findet deshalb Wege, ein Feature so in mehrere kleine Features aufzusplitten, dass jedes für sich genommen auch einen Nutzen stiftet.

Ich hoffe, ich konnte Dir mit diesem Artikel ein paar hilfreiche Tipps für Dein nächstes Backlog Refinement mit auf den Weg geben. Falls Du noch Fragen, Ideen, Anregungen oder Kritik hast, schreib mir gerne einen Kommentar unten auf der Seite. Ich freu mich auf Dein Feedback.