Erfolgreiches Backlog Refinement durchführen

Ein Leitfaden für jede Person, die ein Backlog Refinement erfolgreich planen und durchführen möchte.

Was ich mit dem Artikel beabsichtige?

Dieser Leitfaden unterstützt die Scrum-Team-Mitglieder bei Vorbereitung, Durchführung und Nachbearbeitung des „Backlog Refinement“-Events. Mit Hilfe des Leitfadens kann jedes Team-Mitglied ein Backlog Refinement durchführen, auch wenn der Product Owner oder Scrum Master mal abwesend ist.

In welchem Kontext spielt der Artikel?

Der Leitfaden entwickelte sich aus:

  1. eigenen Erfahrungen in einem bestimmten Projektkontext und Organisationskontext
  2. aus nützlichen Hinweisen aus Literatur über Agile Softwareentwicklung

Der Leitfaden dient der Orientierung und Inspiration seinen eigenen Refinement-Prozess zu gestalten. Für jede Organisation und jedes Team wird sich ein optimaler Prozess anders entwickeln und gestalten.

Die folgenden Abschnitte beschreiben die Prozessschritte, die zu erfolgreichen Backlog Refinements führten.

1. Vorbereitung

Einladung für die relevanten Teilnehmer vor dem Refinement-Termin aktualisieren

Termine, Räume und Teilnehmer können sich jederzeit ändern. Damit jeder informiert ist, sollten die Einladungen angepasst werden und rechtzeitig vor dem Termin versandt werden.

Raum vorbereiten

Ist der Raum aufgeräumt? Sind alle notwendigen Materialien (Board, Sticky Notes, Whiteboard, etc.) verfügbar? Funktioniert der Beamer? Gibt es Getränke und Erfrischungen?

Scrum Board und relevante Inhalte vorbereiten

Das Board und Backlog so vorbereiten, dass das Team mit dem Refinement der relevanten Stories ohne Verzögerung beginnen kann. Welche Stories für das Refinement relevant sind, sollte vor dem „Refinement“-Event entschieden sein. Die Inhalte sollten vorab in der Einladung als Agenda mitversendet werden. Diese Entscheidung triff das Produkt-Team mit Hilfe von Priorisierungen und Scoping-Workshops.

TIPP: nicht einfach das JIRA an die Wand beamen. Viel besser arbeitet es sich an einem physischen Board. Dort kann jeder Notizen, Ergänzungen oder Anpassungen machen. Später kann alles ins JIRA übertragen werden.

Werkzeug für agiles Schätzen einpacken

Scrum Poker ist eine verbreitete Schätzmethode. Im Refinement wird geschätzt. Daher: Scrum Poker nicht vergessen!

Timer für Time-Box einpacken

Jede Story die verfeinert wird, sollte im Rahmen einer Time-Box verfeinert werden. Beispiel: Pro Story eine Time Box von 10 Minuten.

Refinement Vorbereitung
Refinement Vorbereitung

2. Durchführung des Refinements

Gemeinsames Verständnis erzeugen

Folgende Fragen sollten vom Moderator / Facilitator beantwortet werden um den Sinn, Zweck und die Motivation für das Refinement für jeden verständlich zu machen und in Erinnerung zu rufen.

  • Warum sind wir hier?
  • Wer ist hier?
  • Was ist das allgemeine Ziel eines Refinements? Was ist die Motivation für das Refinement?
  • Wie gehen wir gemeinsam vor? Z.B. Dauer des Workshops, Time Box, erklären usw.
  • Was werden wir konkret machen (Agenda)?
Refinement Gemeinsames Verständnis
Gemeinsames Verständnis über den Workshop erzeugen

Review (Rückblick) durchführen

Folgende Fragen sollten vom Moderator / Facilitator beantwortet werden:

  • Was wurde bisher für das Release geschafft?

Überblick über das aktuelle Opportunity und Product Backlog geben

Folgende Fragen sollten vom Moderator / Facilitator beantwortet werden:

  • Was sind die aktuellen Prioritäten?
  • Worauf liegt aktuell der Fokus?
Refinement review
Review und Durchsicht der Backlogs und Prioritäten

Inhalte „refinen“

Folgende Schritte sind empfehlenswert:

  • Auswahl und Vorstellen der Stories für die nächsten 1 bis 3 Sprints
  • Diskutieren der Story
  • Entscheidung treffen: Kommt die Story in das Produkt-Backlog oder zurück in das Opportunity Backlog (1) 
  • Konkrete Tasks ableiten, um die Story „ready“ zu bekommen. Tipp: Tasks sollten SMART (2) sein.
  • Erarbeiten von Akzeptanzkriterien
  • Schätzen der Story
  • Sind sich alle einig, dass die Story „ready“ ist bzw. die “definition of ready“ erfüllt (3)
"Refinen" - Verfeinern der Backlog Items
„Refinen“ – Verfeinern der Backlog Items

Zusammenfassung der wichtigsten Ergebnisse

Folgende Fragen sollten vom Moderator / Facilitator beantwortet werden:

  • Welche Stories haben wir „refined“?
  • Wo finden wir die „Stories“ im Product Backlog?

Ausblick auf die nächsten Workshops geben

Folgende Fragen sollten vom Moderator / Facilitator beantwortet werden:

  • Was sind die nächsten Aktivitäten?
  • Wie geht es weiter?
Ende des Workshops mit Zusammenfassung und Ausblick
Ende des Workshops mit Zusammenfassung und Ausblick

3. Nachbereitung

  • Backlog in JIRA aktualisieren
  • Offene Punkte klären
  • Nächste Workshops und Refinements planen und vorbereiten
Tätigkeiten nach dem Refinement-Workshop
Tätigkeiten nach dem Refinement-Workshop

Zusammenfassung

Das Backlog Refinement zählt zu den wichtigsten Events agiler Software-Entwicklung. Die beschriebenen Schritte und Empfehlungen ermöglichen einen erfolgreichen Ablauf des Backlog Refinements. Auf diese Weise können Stories „ready“ gemacht werden für die Implementierung und das Coding im Sprint. Das Backlog Refinement lebt von der gemeinsamen Zusammenarbeit im Team. Nur so kann das geballte Wissen und die geballte Erfahrungen eines Scrum-Teams nach aussen treten und das Produkt mit dem angestrebten Mehrwert für die Endbenutzer bzw. Kunden bekleiden.

Welche Erfahrungen, positiv wie negativ, machten Sie mit Backlog Refinements?

Welche Wege haben Sie und ihr Team gefunden „Refinements“ erfolgreich durchzuführen?

Ich freue mich über Austausch und Diskussion.

Referenzen

  1. Patton, Jeff. User Story Mapping . O’Reilly Media. Kindle-Version.
  2. https://de.wikipedia.org/wiki/SMART_(Projektmanagement)
  3. https://www.romanpichler.com/blog/the-definition-of-ready/

Über den Autor

Andreas Lehner – Product Owner / UX Design

Trainer und Berater bei der OPITZ CONSULTING Deutschland GmbH. Er verfügt über 12 Jahre Erfahrung in der IT-Beratung von Großunternehmen. Seine Schwerpunkte sind die Schnittstellen von Mensch und Maschine. Das Fundament seiner Arbeit und Denkweise sind Design-Methoden sowie agile Prinzipien.

https://www.linkedin.com/in/andreaslehner/

3 thoughts on “Erfolgreiches Backlog Refinement durchführen”

  1. Erstmal super Artikel, toller Aufbau, sehr verständlich. Danke für die Inspiration. 🙂

    Grundsätzlich finde ich die Idee eines festen Zeitpunktes zum Refinen super. Ich kenne das Backlog Refinement bisher nur als theoretisch kontinuierlichen, täglichen Vorgang durch jedes einzelne Teammitglied, der aber leider gerne mal vergessen werden kann.

    Dennoch: Wollen wir wirklich beim Refinen Planning Poker spielen? Sollten Aufwände für fertig refinte Stories nicht eher im Sprint-Planning geschätzt werden? Sind die Ergebnisse eines einzelnen Meetings wirklich besser, als die eines kontinuierlichen, täglichen Prozesses? Aus meiner Sicht leidet die Agilität doch etwas, wenn wir zum Refinen extra ein Meeting einberufen. ist aber auch nur meine persönliche Sichtweise. Habe ich hier etwas falsch verstanden?

    LG,
    Marko

    1. Hi Marko, vielen Dank für Dein Feedback 🙂

      zu Deinen Anmerkungen:
      1. Ich stimme Dir voll und ganz zu, dass Backlog Refinement kontinuierlich, also täglich, durchgeführt werden sollte. Meist vom Product Owner und dem Product Team. Meist läuft ja parallel zu den Entwickler-Sprint, die Arbeit der „Discovery“ (so wie es Jeff Patton Autor von User Story Mapping nennt). Im Idealfall gibt es auch Erkenntnisse aus User Reserch, die das Backlog massgeblich beeinflussen. So sollte der PO wirklich täglich die Änderungen durch das Refinement pflegen.

      2. Der wöchentliche Workshop ist wichtig (ich nenne es nicht Meeting, da ich auch hier Jeff Patton und Jeff Gothelf zitieren möchte:“Meeting is another word for bad collaboration ;)). Der regelmäßig Termin erzeugt gemeinsames Verständnis im Product / Scrum Team. Und die Entwickler können erste Einschätzungen geben: ist es machbar, wie ist es machbar, gibt es bessere Lösungen, sollte die Story weiter aufgeteilt werden, benötigt die Story noch mehr „Fleisch“ um von den Entwicklern gebraten und zubereiten zu werden usw. Zudem nimmt der regelmäßige Termin ähnlich wie bei Dailys Komplexität aus der tägichen Arbeit.

      3. Schätzen: Finde ich auch im Refinement wichtig. Denn die Schätzung ist guter Indikator für die Größe einer Story. Idealweiser schätzen die Teams mit Story Points die Komplexität. So gewinnt das Team Erkenntnisse wie: Ist die Story möglicherweise zu komplex , sollte das Team die Story splitten und noch weiter verfeinern usw.

      Soweit meine Sicht der Dinge. Ich hoffe meine Punkte sind hilfreich 🙂

      1. Hi Andreas,
        cool, dass Du so schnell antwortest und mich aus meiner Verwirrung befreist. Ich möchte hier bestimmt nicht sinnlos herumkritisieren, sondern bin tatsächlich an einem fachlichen Austausch interessiert. Falls meine Wortwahl manchmal etwas wirsch wirken mag, so ist das definitiv nicht von Aggression getrieben. (Wollte ich vorweg nur einmal erwähnen.n:-) )

        Zu Punkt 1: Kann ich aus eigener Erfahrung absolut unterstreichen. Gut, dass der Aspekt „User Research“ hier noch Erwähnung findet. Wird in der Praxis leider immer noch zu häufig als zu aufwändig abgetan.

        Zu Punkt 2: Finde es gut, dass es einen regelmäßigen Termin gibt – aber einmal pro Woche ist für sich allein genommen, aus meiner Sicht, nicht wirklich ausreichend für ein zielführendes, effektives Refinement. Um den Vorgang des kontinuierlichen, täglichen Refinements jedoch einzuschärfen ist der wöchentliche Workshop sicher eine sehr gute Methode. 🙂 Danke für die nochmalige Erklärung.

        Zu Punkt 3: Kann man so machen. Als vorläufigen Indikator. Verstehst Du den Refinement-Workshop als vorgelagerte Veranstaltung direkt vor dem Sprint Planning? Wo würdest Du ihn einordnen? Wenn wir z.B. lange Sprints von vier Wochen haben, dann ist ein wöchentlicher Refinement-Workshop sicher recht praktisch. Wenn aber – wie so oft – nur in kurzen, einwöchigen Sprints gearbeitet wird, dann wäre der Refinement-Workshop entweder extrem kurz zu halten und würde in jedem Fall einen management-Overhead bilden, so wie es bei einwöchigen Sprints eigentlich immer der Fall ist.

        Sprints sollten eigentlich ja auch nie weniger als zwei Wochen dauern, eben weil Entwickler dann das Gefühl bekommen, vor lauter Meetings nicht mehr wirklich Zeit zum entwickeln zu haben.

Schreibe eine Antwort zu Andreas Lehner Antwort abbrechen

Diese Website verwendet Akismet, um Spam zu reduzieren. Erfahre mehr darüber, wie deine Kommentardaten verarbeitet werden.

%d Bloggern gefällt das: