Zu keinem anderen „Event“ werden mir mehr Fragen gestellt als zum Product Backlog Refinement. Die „Top 3“ der Fragen lauten:
- Wie häufig soll es stattfinden?
- Wie werden Einträge des Produkt Backlogs verfeinert?
- Wer soll dazu eingeladen werden?
Werden diese Fragen nicht beantwortet, dann erlebe ich immer wieder dasselbe: Unzählige Meetings enden ohne klare Anforderungen. Dies passiert entweder, weil die falschen Teilnehmer im Raum sind. Oder es wurde eine unpassende Refinement-Technik genutzt.
Der Scrum Guide beschreibt Product Backlog Refinement so:
„Das Refinement des Product Backlogs ist der Vorgang, durch den Product-Backlog-Einträge in kleinere, präzisere Elemente zerlegt und weiter definiert werden. Dies ist eine kontinuierliche Aktivität, wodurch weitere Details wie Beschreibung, Reihenfolge und Größe ergänzt werden.“
Mit diesem Ziel:
„Product-Backlog-Einträge, die durch das Scrum Team innerhalb eines Sprints abgeschlossen (Done) werden können, gelten als bereit für die Auswahl in einem Sprint-Planning-Event.“
Es geht im Refinement also darum, vage Ideen in gut verstandene Anforderungen an das Produkt zu überführen, die bereit zur Umsetzung sind. Da dies niemals in einem einzelnen Event oder gar Meeting passieren kann, bezeichnet der Scrum Guide es als Aktivität.
Dieser Prozess ist in der folgenden Übersicht auf der linken Seite abgebildet. Das Bild stammt von Dr. Charles Suscheck, einem Trainerkollegen von mir bei Scrum.org.
Lies weiter, dann beantworte ich die eingangs gestellten Fragen anhand dieser Übersicht und gebe dir eine Anleitung, an der du dich orientieren kannst.
Beginnen wir mit der Frage:
Woher kommen die Ideen für neue Einträge im Produkt Backlog?
Die Antwort sollte lauten: Von Stakeholdern des Produkts, Kunden oder Nutzern des Produkts – und dort beginnt das Refinement.
Beginne das Refinement mit Stakeholdern und Kunden
Ein Stakeholder für das Produkt kann jeder sein, der ein Interesse am Produkt hat (etwa Nutzer) oder Einfluss auf das Produkt ausübt (etwa Kunden, Management). Diese Personen können alle zur Generierung neuer Ideen für das Produkt beitragen oder sollten in die Ideenfindung einbezogen werden.
Drei beispielhafte Aktivitäten für diese Phase des Refinements:
Daten- und Markttrendanalyse: In dieser Refinement-Aktivität werden Informationen über einen Markt und die Wettbewerbslandschaft gesammelt und ausgewertet. Das Ziel ist es, Entscheidungsgrundlagen zu erhalten, worin Zeit und Budget investiert werden könnte.
Kundeninterviews und -umfragen: Ziel von Interviews oder Umfragen ist es, die Bedürfnisse, Erfahrungen, Verhaltensweisen, Motivationen und Einstellungen der (potenziellen) Nutzer des Produktes zu verstehen.
(Kundeninterviews führen, Personas erstellen und Annahmen zu validieren ist ein Fass ohne Boden! Wenn du bereit bist, darin abzutauchen, dann besuche Boris Steiner und mich in unserem „Professional Scrum mit UX“-Training. Dort widmen wir uns diesen Themen zwei volle Tage.)
Schätzen von Wert: Um die Lösung von Kundenproblemen zu priorisieren, ist es hilfreich, den Wert der Lösung für einzelne Probleme zu verstehen. Hierzu kannst du zum Beispiel die „Buy a Feature“-Technik von Innovation Games nutzen.
Erkenntnisse dieser frühen Phase des Refinements lassen sich im Produkt Backlog als Eintrag bestehend aus einem Titel und grober Beschreibung festhalten. Stammen die Ideen aus Nutzerinterviews, dann lassen sich auch User Stories formulieren.
Häufig werden User Stories wie folgt festgehalten:
„Als [Rolle] möchte ich [Funktion], um [Nutzen].“
Aus meiner Erfahrung ist dies in dieser Phase des Refinements nicht sinnvoll, da die Funktion noch nicht bekannt ist. Dieses Format lenkt auch vom Wesentlichen ab: dem Nutzen! Um dieses Problem zu vermeiden, formuliere die User Story besser so:
„[Nutzen] für [Rolle] ermöglichen/sicherstellen“
Ein Beispiel: Wenn es sich beim Produkt um eine Buchungsseite für Hotels handelt und Kunden, die häufig reisen und viele Hotels buchen müssen, wenig Zeit beim Buchen verschwenden wollen, dann könnte der Eintrag lauten:
„Zeitersparnis für Vielreisende ermöglichen.“
Wieder zurück zur Übersicht. Um die vagen Ideen im Produkt Backlog besser zu verstehen, sollten wir eine weitere Gruppe von Stakeholdern zu den Gesprächen hinzunehmen. In der Übersicht siehst du diese an der Überlappung der Bereiche auf der rechten Seite mit der Aufschrift „Workshop“.
Um vage Ideen weiter zu konkretisieren, kannst du Fachexperten hinzuziehen
Als Nächstes könnte es hilfreich sein, die Ideen auch mit Fachexperten zu besprechen. Fachexperten könnten Domänen-Experten, Enterprise-Architekten, Test-Manager, Mitarbeiter des Vertriebs, UX-Researcher, Kollegen aus der Rechtsabteilung usw. sein. Es handelt sich um Personen, die einen Einfluss auf das Produkt haben, allerdings nicht Teil des Scrum Teams sind. Je konkreter die Ideen werden, desto mehr sollten auch die Entwickler des Scrum Teams einbezogen werden.
Drei beispielhafte Aktivitäten für diese Phase des Refinements:
UX-Fishbowl: Dieses Diskussionsformat hilft zu erforschen, wie die Umsetzung von Product-Backlog-Einträgen aus der Perspektive der Fachexperten und Stakeholder aussehen könnte und welche Aspekte dabei zu beachten sind.
Visualisieren mittels User Story Mapping: Hierbei werden die User Stories in einer zweidimensionalen Struktur visualisiert. Horizontal werden die Stories nach ihrem Ablauf im Nutzungsprozess angeordnet, was eine Art „Reise des Nutzers“ durch das Produkt abbildet. Vertikal werden die Stories nach ihrer Priorität oder ihrer Versionierung (z. B. Basisfunktionen, erweiterte Funktionen) sortiert.
Schneiden von Product-Backlog-Einträgen: Hierbei können Product-Backlog-Einträge etwa folgendermaßen zerkleinert werden:
- Workflowschritte,
- Happy- und Unhappy-Pfad sowie
- unterschiedliche Nutzerrollen.
Die Ergebnisse dieser Aktivitäten – neben kleineren Product-Backlog-Einträgen – können auch als Akzeptanzkriterien in den Einträgen festgehalten werden. Die Formulierung von Akzeptanzkriterien erhöht die Transparenz darüber, was erforderlich ist, um eine Arbeit zur Zufriedenheit aller Beteiligten abzuschließen.
Ein Beispiel für ein Akzeptanzkriterium, welches Kollegen aus der Rechtsabteilung wichtig sein könnte: Wenn sich ein Nutzer auf der Buchungsseite mit E-Mail-Adresse und Passwort registriert, dann muss sichergestellt sein, dass er die AGBs gelesen und bestätigt hat.
Ziehe die Entwickler des Scrum Teams hinzu, damit die Einträge im Product Backlog bereit für die Umsetzung werden
Je weiter wir uns von der Verstehensphase der Problemstellung hin zu konkreten Lösungsideen bewegen, desto mehr sollten die Entwickler im Scrum Team einbezogen werden. Entwickler in Scrum meint hier nicht nur Softwareentwickler, sondern alle, die einen Aspekt der Lösung entwickeln, etwa Designer, Tester, technische Redakteure. Dies ist im Überblick mit dem Bereich „Meeting“ gekennzeichnet.
Drei beispielhafte Aktivitäten für diese Phase des Refinements:
Schätzen des Aufwands: Hierbei hat sich Planning Poker für viele Teams bewährt. Es hilft, im Team ein gemeinsames Verständnis zu Einträgen im Produkt Backlog und deren Größe zu erlangen. Das Vorbild ist eine Pokerrunde: Alle Entwickler decken gleichzeitig eine Schätzung der Größe auf.
Zerkleinern von Einträgen mithilfe der Hamburger-Methode: Wir nutzen hier eine vereinfachte Version. Die ursprüngliche Methode geht auf Gojko Adzic zurück. Dabei wird eine User Story in Teilschritte aufgeteilt, die ein Nutzer unternimmt. Und dann werden für jeden dieser Teilschritte technische Lösungsideen gebrainstormt. Aus diesen Ideen wird dann eine ausgewählt. So kann die User Story etwa mit minimalem Aufwand erfüllt werden.
(Wenn du die Hamburger-Methode selbst ausprobieren willst, dann besuche mein „Professional Scrum Product Backlog Management Skills“-Training. Dort erkläre ich dir alle Feinheiten und beantworte alle deine Fragen.)
Hinzufügen von Kriterien zur Verifizierung oder Umsetzung: Neben Akzeptanzkriterien können jetzt auch noch Testfälle oder Beschreibungen von Lösungsideen im Product-Backlog-Eintrag festgehalten werden.
Hier ein Beispiel, wie Testkriterien formuliert werden können:
- Gegeben sei: Der Benutzer ist auf der Login-Seite und hat bereits einen gültigen Benutzernamen und ein Passwort eingegeben.
- Wenn der Benutzer auf den Anmelde-Button klickt, …
- … dann sollte der Benutzer zur Hauptseite weitergeleitet werden.
Warnung: Diese Anleitung ist nicht als schrittweise Abfolge des Refinements misszuverstehen
Einträge sollten also mehrfach verfeinert werden.
Die Aktivitäten und beteiligten Personen, die nötig sind, damit ein Eintrag des Produkt Backlogs verständlicher wird, unterscheiden sich von Eintrag zu Eintrag. (Achtung: Immer dasselbe Vorgehen mit den gleichen Personen zur gleichen Zeit, bedeutet eine Entwicklung nach dem Wasserfallmodell!)
Das Ziel des Refinements liegt darin, ein sukzessives Verständnis vom Problem zur Lösung zu erlangen. So lange, bis die Entwickler sich bereit fühlen, an diesem Eintrag zu arbeiten. Überlege dir deshalb immer, wer im Moment die nötigen Personen sind, welche Technik passt und welche Form der Zusammenarbeit (etwa Meeting, Workshop, Datenanalyse) dein Team diesem Ziel näherbringt.