5 2 Votes
Artikel-Rating

Das Product Backlog Refinement sorgt dafür, dass Euer Product Backlog seinen wichtigsten Zweck erfüllen kann: Transparenz über die noch zu erledigende Arbeit zu erzeugen. Da das Product Backlog ein dynamisches Scrum Artefakt ist und fortlaufend neue Informationen (und Aufgaben) hinzukommen, ist es notwendig, es ebenso regelmäßig zu pflegen.

Was geschieht überhaupt im 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).

  • Dein Scrum Team schreibt gemeinsam neue User Stories und Features (oder sogar Epics) ins Product Backlog.

  • Ihr verseht User Stories, Features und Epics mit neuen Informationen und definiert diese bestenfalls als Akzeptanzkriterien.

  • Dein Team identifiziert Abhängigkeiten zu externen und internen Abteilungen bzw. Teams und erörtert Möglichkeiten, sie zu eliminieren.

  • Ihr splittet (zu) große User Stories, Features oder sogar Epics in kleinere Einheiten, um Komplexität zu reduzieren.

  • Dein Team entfernt unnötige oder nicht mehr sinnvolle Product Backlog Items.

  • Ihr verändert gemeinsam die Priorisierung des Product Backlogs.

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.

Was zeichnet ein effizientes Backlog Refinement aus?

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.

Wie viel Zeit sollte ein Scrum Team in das Backlog Refinement investieren?

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.

Wann und wie oft sollte das Backlog Refinement stattfinden?

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.

Wer nimmt am Backlog Refinement Teil?

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

  • Dem Product Owner kommt dabei vor allem die Aufgabe zu, sich zu denjenigen User Stories, die besprochen werden sollen, gut vorzubereiten. Außerdem kann er auch neue Anforderungen an das Produkt zum Refinement mitzubringen. (Das kann lediglich eine Idee für ein Produkt-Feature sein, die gemeinsam weiter ausgearbeitet werden soll.)

  • Der Scrum Master übernimmt in erster Linie die Moderation des Meetings, um sicherzustellen, dass das Scrum Refinement seinen Zweck erfüllt.

  • Die Entwickler des Scrum Teams haben während des Product Backlog Refinements die Möglichkeit, klärende Rückfragen an den Product Owner zu stellen, sodass das Team am Ende des Refinements mehr Transparenz darüber hat, was zu tun ist, um eine bestimmte User Story (oder ein Feature) umzusetzen. Sie können aber durchaus auch eigene Ideen für Features etc. einbringen.

  • Außerdem könnt Ihr auch Gäste zu Eurem Backlog Refinement einladen. Das können beispielsweise Kollegen aus anderen Abteilungen oder Teams sein, die technisches Wissen besitzen, das Euch (noch) fehlt. Wenn Dein Scrum Team in einem Kundenprojekt arbeitet, kann es auch hilfreich sein, Projektleiter oder auch Entwickler auf Kundenseite zu Euerem Refinement einzuladen. So vermeidet Ihr lange Kommunikationsketten und das Stille-Post-Syndrom.

Ist das Refinement in Scrum verpflichtend?

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 Scrum Nexus ist. Bei Nexus gibt es neben den teaminternen Backlog Refinements ein sogenanntes Cross-Team Refinement. Das Cross-Team Refinement ist verpflichtend und beantwortet zwei wichtige Fragen:

  • Welches Team wird ein bestimmtes Product Backlog Item bearbeiten?

  • Gibt es teamübergreifende Abhängigkeiten? Falls ja, welche sind das und wie können wir sie eliminieren?

4 Tipps für Dein nächstes Backlog Refinement

Erfahrungsgemäß tauchen einige Probleme und Fehler während des Scrum Refinements immer wieder auf. Deshalb habe ich hier noch vier hilfreiche Tipps für für Dich zusammengestellt.
0
Kennst Du noch weitere hilfreiche Tipps? Schreib mir gerne einen Kommentar, falls ich etwas vergessen hab.x

Beginnt neue Themen auf Feature- oder Epic-Ebene

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.

Geht nicht zu sehr ins Detail

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.

  • Der Plan für die konkrete Umsetzung einer User Story (oder eines Features) gehört in das Sprint Planning.

Nutzt das Refinement als Wissensaustausch

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.

Achtet darauf, dass jedes Item weiterhin Nutzen stiftet

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.

Fazit zum Scrum Refinement

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.