Simon Flossmann

Im Jahr 2022 ist Scrum inzwischen Mainstream – und dank des Erfolgs von Produkten wie dem iPhone von Apple, dem Kindle von Amazon oder der Suche von Google gilt dasselbe auch für User Experience.

Es gibt zwei Arten von Product Ownern...

Produktentwicklung beginnt und endet mit Produktentdeckung. 2015 habe ich das Buch Lean UX gelesen. Überzeugt davon, dass Entdeckungsarbeit das Fundament der Produktentwicklung darstellt, fing ich an, die UX-Praktiken, die Jeff und Josh in ihrem Buch vorstellen, bei meiner Arbeit als Product Owner einzusetzen. Im Jahr 2018 besuchte ich das Professional Scrum mit UX-Training, um meine Erfahrungen, wie Scrum Teams erfolgreich User Experience in ihre Arbeit integrieren können, auf fundierte Beine zu stellen. Seither habe ich vielen Scrum Teams geholfen, Entdeckung, Entwicklung und Validierung in ihrer Arbeit zu vereinen, um ihren Nutzern frühzeitig Wert zu liefern. Im Folgenden findest du 5 Praktiken, die sich bei meiner Arbeit über die Jahre bewährt haben und die auch dir helfen können, UX- und Entwicklungsarbeiten in einem Sprint zu vereinen. Entdeckungsarbeit sollte Bestandteil des Product Backlogs sein Sollte UX-Arbeit in einem separaten Backlog verwaltet werden? Auf keinen Fall. Mehrere Product Backlogs berauben den Product Owner der Möglichkeit, alle anfallenden Arbeiten in eine eindeutige Reihenfolge zu bringen. Dieses Vorgehen kann Teams weg von Scrum und hin zu einer phasenweisen und wasserfallartigen Entwicklung führen. Im schlimmsten Fall kann dies in getrennten Teams enden. Nur wenn alle Arbeiten, die getan werden müssen, in einem Product Backlog gelistet sind, kann der Product Owner wirklich den Wert maximieren, der aus der Arbeit des Scrum Teams entsteht. Deshalb sollten UX-Arbeiten eigene Elemente im Product Backlog sein. Allerdings ist eine häufige Folge von dieser Praktik, dass Abhängigkeiten zwischen den einzelnen Einträgen im Product Backlog entstehen. Zum Beispiel könnten nun für einige Einträge zuerst Entdeckungsarbeiten anfallen und für andere Einträge ist nach der Lieferung des Inkrements zusätzliche Validierungsarbeit erforderlich. Werden die Product-Backlog-Einträge in zwei Sorten aufgeteilt, also in Einträge, die als Ergebnis die Lieferung von Software haben, und solche, die als Ergebnis das Lernen und Validieren haben, kann dies wieder zu Silos oder einem Miniwasserfall im Team führen. Wie entkommen Scrum Teams dem Miniwasserfall? Damit sich Scrum Teams einfacher auf die Wertschöpfung fokussieren können und der Product Owner die Product-Backlog-Einträge nicht nach Abhängigkeiten, sondern nach dem möglichst hohen Wert ordnen kann, hat es sich als hilfreich erwiesen, die UX-Arbeit zum Bestandteil von Product-Backlog-Einträgen zu machen. UX-Aktivitäten und Arbeiten können Bestandteil des Refinements der Einträge sein, als Task der Product-Backlog-Einträge umgesetzt werden und als Qualitätskriterien aufgelistet sein, wie Akzeptanzkriterien oder Kriterien der Definition of Done. Betrachten wir ein Beispiel, um das zu veranschaulichen. Für den Product-Backlog-Eintrag „Verbesserung der Kreditkartenvalidierung beim Check-out“ könnte im Zuge des Refinements ein erstes UI-Design skizziert worden sein. Ein Task eines Product-Backlog-Eintrags könnte dann „Fehlermeldungen, wenn der Benutzer die Kreditkartennummer falsch eintippt, sind überprüft“ oder „Entwurfsession für UI-Elemente und Arbeitsabläufe, Wireframe haben stattgefunden“ lauten. Akzeptanzkriterien oder Elemente der Definition of Done könnten lauten: „Das Scrum Team hat ein Interaction Review durchgeführt“, „Alle UI-Designs sind im Einklang mit dem Brand Guide“ und „UX-personabasierte explorative Tests wurden durchgeführt“. Sehen Scrum Teams UX-Aktivitäten als Teil von Product-Backlog-Einträgen, so unterstützt dies die Teammitglieder im Sprint funktionsübergreifend zusammenzuarbeiten. Dauert Entdeckungsarbeit länger als ein Sprint, sollte dieses Risiko transparent gemacht werden Was haben die folgenden Beispiele gemeinsam? Die Verwendung einer Fitness-App soll optimiert werden. Dazu soll eine Studie der aktuellen Verwendung und des Sportverhaltens der Nutzer erstellt werden. Die Studie umfasst Interviews, Tagebuchstudien und Beobachtungen im eigenen Kontext. Die Studie soll 21 Benutzer erfassen und wird etwa 8 – 10 Wochen dauern. Für die Optimierung einer Anwendung zur Steuerberechnung werden langfristige quantitative Daten von Nutzern benötigt. Die Daten müssen dabei die Verwendung über ein ganzes Steuerjahr hinweg protokollieren und mindestens 3 % aller Nutzer umfassen, um aussagekräftig zu sein. Bei beiden Beispielen geht es nicht primär um die Anzahl der benötigten Nutzer, sondern darum, dass ein aussagekräftiger Datensatz nur über einen längeren Zeitraum aufgebaut werden kann. Dies sind zwei extreme Beispiele von UX-Aktivitäten, die länger als vier Wochen dauern. Allgemein stellt sich die Frage: Wie sollten Scrum Teams mit Arbeiten umgehen, die länger dauern werden als ein Sprint? Scrum Teams, die wirklich agil arbeiten wollen, sollten nichts unversucht lassen, um die Arbeit so fein wie möglich aufzuteilen, ohne den resultierenden Wert der Arbeit zu beeinträchtigen. Bei Interviewserien sollten sie stets hinterfragen: Ist nicht bereits ein einziges Interview wertvoll? Können wir nicht die ersten Ergebnisse im Refinement, Daily Scrum oder Sprint Review weitergeben, während wir für statistische Signifikanz weitere Interviews durchführen? Aus meiner Erfahrung ist das häufig möglich und es hilft, frühzeitig den Interviewprozess zu verbessern und das restliche Scrum Team am Fortschritt und den Resultaten partizipieren zu lassen. Wenn wir die UX-Arbeit nicht kleiner schneiden können, dann stellt sie aus Produktmanagementsicht ein Risiko dar. Wir sollten nicht vergessen: Die Sprintlänge dient in Scrum, zusammen mit dem fertigen Inkrement, dem aktiven Risikomanagement. Alles, was länger als ein Sprint dauert, stellt somit ein erhöhtes Risiko dar. Dieses Risiko gilt es transparent zu machen. Zum Beispiel, indem das Scrum Team sein Sprint-Backlog-Board um die Spalten „Entdeckung“ und „Validierung“ erweitert und diese Arbeiten dort aufnimmt. Die Scrum Events, allen voran das Daily Scrum, helfen dann, den Fortschritt dieser Arbeiten zu überprüfen. Und sollte doch Unerwartetes eintreten, kann das Team reagieren und Anpassungen an diesen Einträgen vornehmen. Nur wenn Scrum Teams die Arbeit transparent machen, besteht die Möglichkeit, den Entwicklungsprozess in Zukunft auch zu verbessern. Bei der Diskussion darüber, wie wir mit Arbeit umgehen sollen, die länger als ein Sprint dauert, sollten wir den Zweck von Scrum – ein Team übernimmt die volle Verantwortung für den Entwicklungsprozess eines Produkts – nicht aus den Augen verlieren. UX-Experten sollten Mitglieder des Scrum Teams sein Sollte UX nicht eine separate Rolle außerhalb des Scrum Teams einnehmen, da sie im Scrum Guide nicht aufgelistet ist? So lautet eine der häufigsten Fragen in meinem Professional Scrum mit UX-Training. Die Antwort lautet: nein. Das Produkt zu testen ist auch eine wichtige Tätigkeit, um die Qualität des Produkts zu gewährleisten und doch ist der Tester keine separate Verantwortlichkeit in Scrum. Gleiches gilt auch für UX-Experten. Und noch mehr: Im Gegensatz zum Testen erwähnt der Scrum Guide sogar explizit die UX-Tätigkeiten Verifikation, Experimente und Forschung als Aktivitäten, für die Scrum Teams verantwortlich sind. „Das Scrum Team ist umsetzungsverantwortlich für alle produktbezogenen Aktivitäten: Zusammenarbeit mit den Stakeholdern, Verifikation, Wartung, Betrieb, Experimente, Forschung und Entwicklung und alles, was sonst noch erforderlich sein könnte.“ Wenn UX-Experten Bestandteil von Scrum Teams sein sollten, wie arbeiten sie dann mit den restlichen Teammitgliedern effektiv zusammen? Aus meiner Erfahrung haben sich zwei Arbeitsmodi als besonders erfolgreich erwiesen. Der erste ist als das Produkt-Trio bekannt. Ein Entwickler, der Product Owner und der UX-Experte bilden das sogenannte Produkt-Trio. Gemeinsam bestreitet dieses Trio Kundeninterviews, Anwenderforschungsaktivitäten, Experimente und alle anderen Aktivitäten, die Nutzer involvieren. Häufig fällt dabei dem UX-Experten die Erstellung, Durchführung und Auswertung des Interviews, dem Product Owner die Protokollierung und dem Entwickler die objektive Beobachtung zu. Anzumerken ist auch, dass der Entwickler nicht immer die gleiche Person sein muss. Im Gegenteil: Wechseln die Entwickler häufig, sorgt das dafür, dass jeder Entwickler regelmäßig die Probleme der Nutzer und Kunden aus erster Hand erfährt, was langfristig zu einer nutzerzentrierten Produktsicht beiträgt. Der zweite Modus ist, dass der UX-Experte alle User-Experience-bezogenen Aktivitäten facilitiert. Neben groß angelegten Befragungen unterstützt er Frontend-Entwickler und UI-Designer bei der Umsetzung, hilft dem Product Owner mit der Erarbeitung der Vision, bei der Suche nach den Metriken, die Outcomes sichtbar machen, in der Priorisierung des Product Backlogs und beim explorativen Testen. Abschließend sollten wir dabei nicht vergessen, dass der Scrum Guide von Entwicklern spricht, nicht um auszuschließen, sondern um zu vereinfachen. Experimente helfen, um die Hypothesen in der Entwicklung risikoarm zu überprüfen Angenommen, wir starten mit der Entwicklung eines neuen Produkts. Was haben folgende Dinge gemeinsam? das aktuelle Business-Problem, welches das Scrum Team lösen will die Lösung für das Business-Problem die Nutzer, die von der Lösung profitieren werden die Vorteile, die die Nutzer genießen, wenn sie die Lösung verwenden die Geschäftsziele, die durch die Bereitstellung einer Lösung erreicht werden sollen Es sind Annahmen. Annahmen sind die bestmögliche Einschätzung nach aktuellem Wissensstand. Annahmen können sich bewahrheiten oder nicht und deshalb bergen sie ein Risiko. Erfolgreiche Scrum Teams eliminieren dieses Risiko so früh wie möglich, indem sie die Annahmen zu einer Hypothese zusammenfassen und testen. Eine Hypothese ist etwas, das das Team mit einem Experiment testen kann. Diese Teams orientieren sich dabei an dem Leitsatz, der Dr. Richard Feynman zugesprochen wird: „Hält [eine Annahme] Experimenten nicht stand, ist sie falsch.“ Wie lassen sich Hypothesen aufstellen? Jeff Gothelf und Josh Seiden schlagen ein einfaches Format vor, um eine Hypothese zu formulieren: Wir glauben[, diese Annahme sei wahr]. Wir werden wissen, ob wir [richtig/falsch] liegen, sobald wir folgendes Feedback von Nutzern erhalten: [qualitatives Feedback] oder [quantitatives Feedback] oder [Änderung einer maßgeblichen Outcome-Metrik]. Eine Hypothese besteht also aus zwei Teilen: Der Annahme, die wir für wahr halten, und einer Aussage zu dem Nutzerfeedback, das wir brauchen, um unsere Annahme zu bestätigen. Wie lassen sich Hypothesen testen? Eine Hypothese zu testen, indem wir die vollständige Lösung entwickeln und dem Nutzer zum Test bereitstellen, ist die teuerste und somit risikoreichste Form eines Experiments. Deshalb stellen sich erfahrene Produkt-Teams frühzeitig die Frage: Welche Experimente können sie machen? Wie viele Beweise liefern diese Experimente? Und wie stehen sie im Verhältnis zum Aufwand? Um den Aufwand von Experimenten ins Verhältnis zu den gewonnenen Erkenntnissen zu stellen, lassen sich Scrum Teams von der „Truth Curve“ von Giff Constable leiten. Hypothesen sollten immer erstmal mit aufwandsarmen Experimenten überprüft werden, zum Beispiel indem wir mögliche Nutzer interviewen oder erste Entwürfe der Lösung mit einem Paper-Prototyp validieren. Wird dadurch die Hypothese, die ein Team aufstellt, nicht widerlegt, haben wir erste glaubhafte Beweise gesammelt. Nun lohnt es sich auch, aufwendigere Experimente zu unternehmen, um weitere Beweise zu sammeln. Erfolgreiche Produkt-Teams haben verstanden, dass alle Produktentwicklungsaktivitäten, die unterhalb der „grünen Kurve“ stattfinden, unnötig risikobehaftet sind und deshalb vermieden werden sollten. Zusammengefasst können wir das Vorgehen, Annahmen zu nutzen, um Hypothesen aufzustellen und diese zu testen, als hypothesengetriebene Entwicklung bezeichnen. Product Owner sollten Entdeckung und Lieferung in jedem Sprint priorisieren Sollte jedes Feature als Hypothese aufgefasst und getestet werden, bevor es entwickelt wird? Da diese Frage von zentraler Bedeutung in der Produktentwicklung ist, gibt es im Scrum Rahmenwerk eine eigene Verantwortlichkeit dafür. Der Product Owner eines Scrum Teams ist dafür verantwortlich, dass der Wert maximiert wird, welcher aus der Arbeit der Entwickler resultiert. Wird eine Produktfunktion einfach entwickelt, ohne ihre Nützlichkeit vorab zu bestätigen und wird sie dann von den Nutzern nicht angenommen, wurde der Wert offensichtlich nicht maximiert, der aus der Arbeit der Entwickler resultiert. Die Entwickler hätten ihre Zeit besser in andere Aktivitäten investieren können. Allerdings gibt es auch Funktionen, die sich Kunden bereits wünschen. Hier könnte übermäßiges vorheriges Testen auch eine Verschwendung der Entwicklungszeit darstellen. Um diesem Dilemma zu entfliehen, stellt der Hypothesis Prioritization Canvas eine gute Entscheidungshilfe für Product Owner bereit. Die horizontale Achse beschreibt die Einschätzung des Risikos einer einzelnen Hypothese. Das Team sollte gemeinsam einschätzen, wie riskant diese neue Idee für das Produkt, das System, die Dienstleistung oder das Unternehmen ist. Da Risiken von der Machbarkeit bis zur Verwendbarkeit und Rentabilität rechnen können, sollte die Einschätzung immer im Team vorgenommen werden, um ein fundiertes Ergebnis zu erhalten. Die vertikale Achse beschreibt den wahrgenommenen Wert. Wichtig: Da es sich hier um eine Hypothese, also eine Vermutung handelt, ist der Wert, den wir uns von unseren Ideen versprechen, genau das: eine Vermutung! Erst wenn eine nutzbare Produktversion der Idee auf den Markt kommt, werden wir wissen, ob sie die Erwartungen erfüllt hat. Werden Product Owner ihrer Verantwortung gerecht und priorisieren Lernen und Liefern in jedem Sprint, praktiziert das Scrum Team Emergent UX. Da die Kosten für ein Scrum Team im Wesentlichen konstant bleiben, entscheidet der Product Owner durch seine Priorisierung, wie viel in Entdeckungs- und Entwicklungsarbeit investiert werden soll. Möchtest Du mehr erfahren? Hoffentlich war dieser Artikel nützlich für Dich. Wie man UX- und Entwicklungsarbeit verbindet, ist eines der vielen interessanten Themen, die in meinen Professional Scrum Trainings behandelt werden. Wenn du keinen neuen Beitrag mehr verpassen willst, dann abonniere meinen Newsletter, dort wirst du als Erster über neue Beiträge informiert. 👉 Hier geht zur Anmeldung.

Da ich bereits „Scrum Master“ bin, dachte ich, ich wäre bereits ein guter Facilitator. Zu meiner Schande muss ich allerdings gestehen, dass ich dabei die Rolle des Facilitators mit der des Moderators verwechselt habe. Was es heißt, ein Facilitator zu sein und was der Unterschied zu einem Moderator ist, wurde mir erst schmerzlich bewusst, als ich am eigenen Leib erfahren habe, wie Barry Overeem und Christiaan Verwijs Workshops und Trainings facilitieren. Ein Moderator steuert, ein Facilitator ermöglicht. Die Dinge, die ich mir von Christiaan und Barry abgeschaut habe, versuche ich seither in meiner Arbeit umzusetzen. In den vergangenen Jahren habe ich über 60 Professional Scrum Trainings gegeben und dabei haben sich 5 Dinge immer bewährt: 1. Wiederhole jede Einladung mindestens zweimal Klar und präzise formulierte Übungseinladungen, die jeder Teilnehmer verstanden hat, sind ein Garant für ein erfolgreiches Training. Um sicherzustellen, dass die Teilnehmer die Übung verstanden haben, ist es wichtig, die Einladung mindestens einmal zu wiederholen und jedem die Möglichkeit zu geben, noch vor der Übung eine Rückfrage zu stellen. Bei der Einladung hat sich für mich folgendes Template bewährt: In wenigen Augenblicken seid ihr eingeladen, in Gruppen zu [Anzahl] Personen folgende Aufgabenstellung zu bearbeiten: [Beschreibung des Übungsergebnisses]. Dafür habt ihr [Anzahl] Minuten Zeit. Bevor ihr mit der Übung beginnt: Gibt es von eurer Seite noch eine Frage zur Übungsdurchführung? 2. Erkläre die einzelnen Übungsschritte zeitnah Wenn ich Übungen anleite, die aus mehreren Einzelschritten bestehen, dann erkläre ich jeden Schritt separat. Ich erkläre den Schritt erst dann, wenn die Teilnehmer diesen auch tatsächlich ausführen. Erklärt man alle Schritte gleich zu Beginn, verwirrt dies die Übenden häufig. Um die Teilnehmer darüber zu informieren, dass die Übung aus mehreren Teilen besteht, ergänze ich die Einladung wie folgt: In wenigen Augenblicken seid ihr eingeladen, in Gruppen zu [Anzahl] Personen folgende Aufgabenstellung zu bearbeiten: [Beschreibung des Übungsergebnis]. Damit wir dieses Übungsergebnis erreichen, sind mehrere Schritte nötig. Im ersten Schritt erarbeitet ihr bitte folgende Teilfragestellung: [Beschreibung des ersten Teilergebnisses] Dafür habt ihr [Anzahl] Minuten Zeit. Bevor ihr mit der Übung beginnt: Gibt es von eurer Seite noch eine Frage zur Übungsdurchführung? Erst nachdem der erste Schritt durchgeführt wurde, erkläre ich den nächsten. So stelle ich sicher, dass die Teilnehmer sich stets nur auf ein zu erreichendes Ergebnis fokussieren müssen. Darüber hinaus haben sie bei jeder weiteren Einladung wieder die Möglichkeit, offene Fragen zu klären. 3. Gib Teilnehmern eine Minute zum individuellen Denken In Workshops oder Meetings beobachte ich häufig, dass sich, nachdem ein Teilnehmer seinen Vorschlag vorgestellt hat, die weitere Diskussion ausschließlich um diese eine Idee dreht. Um diese einseitige Sicht auf eine Fragestellung zu verhindern, hat es sich für mich bewährt, jedem Teilnehmer einen Moment des eigenständigen Nachdenkens zu geben. Wenn jeder Teilnehmer die Möglichkeit bekommt, erst eine eigene Antwort auf eine Frage zu formulieren, erhöht dies die Wahrscheinlichkeit, dass in der anschließenden Zusammenarbeit auch unterschiedliche Lösungsansätze betrachtet werden. Um diese Methode umzusetzen, kann man entweder den kurzen und stillen Moment als ersten Schritt in die Übungsanleitung aufnehmen oder die Einladung wie folgt anpassen: In wenigen Augenblicken seid ihr eingeladen, in Gruppen zu [Anzahl] Personen folgende Aufgabenstellung zu bearbeiten: [Beschreibung des Übungsergebnisses]. Dafür habt ihr [Anzahl] Minuten Zeit. Bevor ihr mit der Übung beginnt: Gibt es von eurer Seite noch eine Frage zur Übungsdurchführung? Wenn ihr euch in eurer Gruppe eingefunden habt, macht ihr euch bitte erst eine Minute in Ruhe eure eigenen Gedanken zur Aufgabenstellung. Erst im Anschluss daran diskutiert ihr eure Ideen mit der Gruppe. Nach meiner Erfahrung hat sich hierbei eine Minute als die perfekte Zeitspanne bewährt. Eine Minute gibt jedem die Chance, seine eigenen Überlegungen zur Einladung anzustellen, und sie ist kurz genug, damit die Teilnehmer nicht abschweifen. 4. Halte die Timeboxen ein Einen Zeitrahmen für Übungen, die sogenannten Timeboxen, festzulegen, ist der Schlüssel für Ergebnisse. In Scrum fördern Sprints, dass sich Scrum Teams auf das Wesentliche fokussieren: Am Ende des Sprints muss ein nutzbares Inkrement zur Verfügung stehen. In Workshops fördert eine fest vorgegebene Timebox, dass sich die Teilnehmer bei der Übung auf das Wesentliche fokussieren: ein Ergebnis zur vorliegenden Fragestellung zu finden, mit dem anschließend weitergearbeitet werden kann. Das Ergebnis wird nicht perfekt sein. Aber anstatt sich auf Perfektion zu konzentrieren, ermutigen Timeboxen die Teilnehmer, sich auf den Fortschritt zu konzentrieren. Um Timeboxing effektiv in Trainings oder Workshops zu verwenden, müssen diese transparent sein. Ich mache die Timebox transparent, indem ich sie zu Beginn einer Übung ankündige und die Uhr, in welcher die Zeit abläuft, für alle sichtbar positioniere. Jede Übung mit einer Minute zum individuellen Denken zu beginnen und nach einer festen Zeitspanne zu beenden, ermöglicht es, die Balance zwischen Kreativität und einer konkreten Lösung zu halten. 5. Achte beim Debrief auf Vielfalt Neben der Einladung ist der Debrief am Ende einer Übung die wichtigste Möglichkeit, um als Facilitator eine Übung zu lenken. Die Einladung ermöglicht es die Richtung bei einer Übung vorzugeben, und der Debrief am Ende einer Übung hilft das Augenmerk auf bedeutsame Aspekte zu lenken. Ein gut facilitierter Debrief verbindet die Arbeit über einzelne Gruppen hinweg, macht Lernziele transparent, hilft Teilnehmern ihre Erfahrungen zu reflektieren und ermöglicht dem Trainer, den Inhalt zusammenzufassen. Die zwei Fragen, die ich häufig verwende, um den Debrief einzuleiten, lauten: Was hat die Übung für euch transparent gemacht? Zu welcher Einsicht, die für die anderen Gruppen auch relevant sein könnte, seid ihr in eurer Gruppe gelangt? Wenn ich nach der Frage die Teilnehmer auswähle, die etwas mitteilen möchten, wähle ich die Personen so aus, dass eine optimale Vielfalt gewährleistet ist. Sollten sich immer nur die gleichen Teilnehmer melden, richte ich die Fragen gegebenenfalls auch direkt an die anderen Teilnehmer.

Was ist Product Backlog Refinement? Scrum Teams machen es ständig. Es passiert im Sprint Review, nach dem Daily Scrum, im Sprint Planning und als Teil der Entwicklung. Sie diskutieren über die bevorstehende Arbeit, um sie zu präzisieren. Präzisieren umfasst: die Ergebnisse und Inhalte ihrer Arbeit klären die Arbeit zerkleinern und aufteilen, sodass die Einzelstücke nach Fertigstellung noch Wert für den Nutzer liefern die Arbeit im Backlog anordnen, sodass die Ziele des Scrum Teams und der Organisation bestmöglich erreicht werden neue Arbeiten, die am Produkt getan werden müssen, zum Backlog hinzufügen und überflüssige Arbeiten entfernen mögliche Abhängigkeiten zu anderen Teams oder innerhalb der Arbeit auflösen die Arbeit in ihrem Umfang und Wert schätzen technische Fragen zur Umsetzbarkeit der Arbeit untersuchen die Arbeit als Vermutungen begreifen Es dreht sich also alles um zukünftige Arbeiten im Product Backlog, ausgedrückt als Product-Backlog-Einträge. Diese Einträge bezeichnet Barry Overeem als Erinnerungen an Gespräche, die in der Zukunft noch geführt werden müssen. Das Refinement ist einfach die fortlaufende Aktivität, diese Gespräche zu führen, und somit eine essentielle Product-Management-Aktivität. Wozu ist das Product Backlog Refinement wichtig? In Gesprächen werden Product-Backlog-Einträge präzisiert und zerkleinert, bis sich ein gemeinsames Verständnis für die Arbeit einstellt. Dies geschieht so lange, bis sich das Scrum Team ziemlich sicher ist, dass sie die anfallende Arbeit innerhalb eines Sprints abschließen kann. Dadurch erreicht das Product Backlog einen Transparenzgrad, welcher das Risiko verringert, am Ende des Sprints mit der Arbeit nicht fertig zu werden. Wird ein Product-Backlog-Eintrag nicht fertig, verschenkt ein Scrum Team die Möglichkeit, neuen Wert für die Organisation zu generieren. Deshalb ist das Refinement eine essentielle Product Management Aktivität, welche erfolgreiche Scrum Teams beherrschen. Beim Refinement werden die Element im Product Backlog betrachtet, die weiter nach oben wandern. Scrum Teams wissen, dass es effizient ist, nur die oberen Elemente im Product Backlog zu präzisieren. Sie werden zwangsläufig Dinge lernen, die ihre Ansichten über Elemente weiter unten ändern oder überflüssig machen. Um das nicht aus den Augen zu verlieren, hilft die Daumenregel, dass jeder Developer nur 10 % ihrer Zeit dafür verwenden sollten. 5 Konkrete Strategien für Product Backlog Refinement Obwohl Refinement eine essentielle Product-Management-Aktivität ist, verwenden laut dem Scrum Zombie Guide 43 % der Scrum Teams im aktuellen Sprint keine Zeit, um die Arbeit für kommende Sprints zu verfeinern. Deshalb werden im Folgenden 5 konkrete Strategien für Product Backlog Refinement vorgestellt: Gewinnen neuer Erkenntnisse Ordnen des Product Backlogs Schätzen von Product-Backlog-Einträgen Zerkleinern von Product-Backlog-Einträgen Auflösen von Abhängigkeiten Diese helfen Scrum Teams und dessen Stakeholder, Gespräche zu führen und damit die Einträge im Product Backlog zu präzisieren. Strategie 1: Gewinnen neuer Erkenntnisse Scrum Teams erlangen ein Verständnis der Arbeit, wenn sie gemeinsam mit ihren Stakeholdern neue Erkenntnisse darüber gewinnen. Hypothesen-Canvas In der Produktentwicklung ist mehr unbekannt als bekannt. Kunden ändern ihre Meinung und Technologien ändern sich. Die Gewohnheit, diese Komplexität mit festen Vorhersagen und detaillierten Plänen beherrschen zu wollen, existiert leider noch in vielen Organisationen, sogar in denen, die Scrum verwenden. Wenn Scrum Teams Produktbedürfnisse, Kundenverhalten und Produkt-Markt-Fit erraten sollen, sind sie oft zum Scheitern verurteilt. Der Schlüssel zum umdenken ist, Scrum Teams als Problemlösungs-Teams zu sehen und nicht als Feature-Lieferfabriken. Erfolgreiche Scrum Teams beginnen nicht damit, Features und Funktionen zu implementieren, sondern damit, über die Probleme des Kunden nachzudenken und Vermutungen über Lösungen aufzustellen. Das Hypothesen-Canvas, basierend auf dem Lean UX Canvas von Jeff Gothelf ermöglicht das und ermutigt Scrum Teams zur kreativen Erkundung von Problemstellungen. Wir glauben, dass wir Fortschritt bei der Erreichung des [Produkt-Ziels] machen, wenn [Benutzer] mit [Funktion] das [Ergebnis] erzielen. Die Idee ist, dass Scrum Teams und deren Stakeholder ihre Ideen nicht als Anforderungen begreifen, sondern als ihre besten Vermutungen darüber, wie sie Wert liefern können. Mit klaren Erfolgskriterien, welche ihnen sagen, welches Ergebnis der Benutzer durch die Verwendung der zu implementierenden Funktion erreicht und welche Auswirkung das auf die Erreichung des Produkt-Ziel hat. Im Refinement erarbeiten Scrum Teams gemeinsam mit ihren Stakeholdern diese Hypothesen und halten sie als Einträge im Product Backlog fest. UX Fishbowl Ein User Experience (UX) Fishbowl ist eine Liberating Structure, welche es ermöglicht, zu erforschen, wie die Umsetzung von Product-Backlog-Einträgen aus der Perspektive der Stakeholder aussehen würde und was diese für sie ermöglicht. Ein UX Fishbowl besteht aus zwei Gruppen und zwei Schritten, eine Gruppe bilden die Stakeholder und eine das Scrum Team. Die Schritte können nacheinander beliebig oft ausgeführt werden. Die Stakeholder werden eingeladen, folgende Fragen zu diskutieren. "Stellen Sie sich vor, diese Funktionalität wäre bereits Teil des Produkts. Wie, wann und warum würden Sie sie verwenden? Welche Schritte sind damit verbunden? Was macht es für Sie nützlich? Was könnte Sie abschrecken?" Das Scrum Team hört aufmerksam zu und notiert wichtige Einsichten. Das Scrum Team kommt zusammen und formuliert weiterführende Fragen, basierend auf dem, was sie gehört haben. Diese Fragen dienen als Fragen für die nächste Runde. Dieser UX Fishbowl eröffnet Scrum Teams Möglichkeiten, große Product-Backlog-Einträge in kleinere zu zerlegen, welche noch wertvoll für Stakeholder sind. Strategie 2: Ordnen des Product Backlogs Product Owner wissen, dass das Ordnen des Product Backlogs nichts ist, was sie allein tun sollten. Wenn Scrum Teams die Ordnung gemeinsam mit den Stakeholder herstellen, gewinnen sie neue Einsichten, was wertvoll für das Produkt sein kann. Buy a Feature Um herauszufinden, welche Produkt-Backlog-Einträge wichtig sind, ist es hilfreich, die Stakeholder, die von der Umsetzung profitieren, miteinzubeziehen. Buy a Feature von Innovation Games ermöglicht das folgendermaßen: Die Product-Backlog-Einträge, die zum Kauf bereitstehen, werden mit einem Preis versehen und zu einer Liste zusammengefasst. Das Geld wird gleichmäßig unter den Stakeholdern aufgeteilt. Die Stakeholder kaufen die Product-Backlog-Einträge, welche am wichtigsten für sie sind. Jeder Eintrag kann einmal gekauft werden. Die Stakeholder können beim Kauf ihr Geld zusammenlegen. Wenn das Geld ausgeben ist, spiegeln die gekauften Einträge der Liste wider, welche Product-Backlog-Einträge den Stakeholdern gemeinschaftlich wichtig sind. Damit die Stakeholder kollaborieren müssen, sollten die Stakeholder insgesamt nur so viel Geld bekommen, dass sie nur die Hälfte der Product-Backlog-Einträge kaufen können und einige Einträge sollten so teuer sein, dass kein Stakeholder sie allein erstehen kann. 20/20 Vision Eine 20/20 Vision zu haben, bedeutet, perfekt zu sehen, ohne eine Brille oder Kontaktlinsen tragen zu müssen. Scrum Teams hilft diese Fähigkeit, die Ordnung des Product Backlogs perfekt aus den Augen ihrer Stakeholder zu sehen. Sie gehen dazu wie folgt vor: Jeder Eintrag des Product Backlogs ist eine eigene Karte. Die Karten werden gemischt und ein verdeckter Stapel gebildet. Die oberste Karte dient als Referenz und wird umgedreht neben dem Stapel platziert. Wenn die nächste Karte aufgedeckt wird, entscheiden die Stakeholder, ob sie ihnen wichtiger oder weniger wichtiger ist, und platzieren sie entsprechend oberhalb oder unterhalb der Referenzkarte. Das Eingruppieren der verbleibenden Karten in die neue Liste wird bis zur letzten Karte des Stapels wiederholt. Es entsteht eine 20/20 Vision der Ordnung des Product Backlogs, welche zeigt, was den Stakeholdern wichtig ist. Strategie 3: Schätzen von Product-Backlog-Einträgen Ziel beim Schätzen ist es, ein gemeinsames Verständnis über die Arbeit im Product Backlog zu erlangen und nicht absolute Sicherheit über den anfallenden Umsetzungsaufwand. Scrum Teams schätzen die Product-Backlog-Einträge, indem die Developer ihnen eine Größenwert zu ordnen. Die Größe drückt dabei nicht die absolute Größe des Product-Backlog-Eintrags aus, sondern die Größe in Relation zu den anderen Einträgen. Scrum Teams bedienen sich relativer Größen, da Menschen Relationen leichter bestimmen können. Magic Estimation Durch Magic Estimation ist es Scrum Teams möglich, eine Product Backlog in so kurzer Zeit zu schätzen, dass es wie Magie erscheint. Folgende Schritte sind dazu nötig: Die Zahlen 1,2,3,5,8,13,21,? der Fibonaccireihe bis 21, ergänzt durch ein Fragezeichen, bilden mögliche Größenwerte. Ein Product-Backlog-Eintrag wird gemeinschaftlich einer Größe zugeordnet und dient als Referenz für die Zuordnung der restlichen Einträge. Die verbleibenden Product-Backlog-Einträge werden unter den Developern verteilt. Die Developer ordnen jedem ihrer Product-Backlog-Einträge eine entsprechende Größe in Relation zum Referenzeintrag zu. Verstehen sie einen Eintrag nicht, wird ihm das Fragezeichen zugeordnet. Während des Zuordnens sprechen sie sich nicht mit den anderen Beteiligten ab. Nachdem alle Product-Backlog-Einträge zugeordnet wurden, schauen sie sich die Zuordnungen der anderen an und ordnen ihnen eine neue Größe zu, falls sie bei der Wahl der zugeordneten Größe nicht übereinstimmen. Lässt sich einem Product-Backlog-Eintrag keine eindeutiger Größenwert zuordnen, wird ihm der größere der beiden Werten zugeordnet. Wurde einem Eintrag ein Fragezeichen zugeordnet, bedarf es weiterer Klärung unter Hinzunahme des Product Owners, bis ihm eine eindeutige Größe zugeordnet werden kann. Das Result ist ein in Relation zum Referenzeintrag geschätzter Product Backlog. Planning Poker Planning Poker, welches auf James Glenning zurückgeht, hilft Scrum Teams, Product-Backlog-Einträge zu verstehen und ein gemeinsames Verständnis über dessen Größe zu erlangen. Das Vorbild ist eine Pokerrunde. Konkret wird wie folgt vorgegangen: Der Product Owner nennt den zu schätzenden Eintrag im Product Backlog und erklärt diesen bei Bedarf. Jeder Developer schätzt individuell den Eintrag, indem er ihm eine Größe zuordnet. Seine Wahl bleibt so lange verdeckt, bis alle geschätzt haben. Danach zeigen alle beteiligten Developer gleichzeitig ihre Wahl. Gibt es keine Übereinstimmung in der Größe für den Product-Backlog-Eintrag, so diskutieren Developer mit den höchsten und niedrigsten Schätzungen ihre Wahlen. Danach wird dieser Eintrag nochmals von allen geschätzt (Schritt 2). Dieser Schritt wird so lange wiederholt, bis eine Einigung erzielt wird. Diese Einigung spiegelt das gemeinsames Verständnis über den Product-Backlog-Eintrag wider. Als Größen eignen sich Finger, Gummibärchen, T-Shirtgrößen oder halt die ersten Zahlen Fibonacchi-Reihe. Strategie 4: Zerkleinern von Product-Backlog-Einträgen Scrum Team zerkleinern Product-Backlog-Einträge, sodass die Umsetzung jedes Eintrags eigenständig nutzbar ist und Wert für den Nutzer stiften kann. Die Arbeit wird vertikal zur Wertschöpfung aufgeteilt. Eine horizontale Zerkleinerung findet erst im Sprint Planning statt, wenn Developer den Plan erstellen, wie ein Product-Backlog-Eintrag umgesetzt wird. Product-Backlog-Einträge nach Workflowschritten zerkleinern Beinhalten Product-Backlog-Einträge einen Arbeitsablauf, können diese in einzelne Schritte zerlegt werden. Der Eintrag, welcher beschreibt, dass ein Kunde die Waren in seinem Warenkorb bezahlen kann, lässt sich in folgenden Einträge aufteilen: Als Kunde kann ich mich mit meinem Konto anmelden. Als Kunde kann ich meine Bestellung bezahlen. Als Kunde erhalte ich eine Bestätigungs-E-Mail mit meiner Bestellung. Product-Backlog-Einträge nach Happy- und Unhappy-Pfad zerkleinern Funktionalität beinhaltet häufig einen Happy-Pfad und einen oder mehrere Unhappy-Pfade. Der Happy-Pfad beschreibt, wie sich die Funktionalität verhält, wenn alles wie gewünscht verläuft. Gibt es Abweichungen, Ausnahmen oder andere Probleme, wird der Unhappy-Pfad aufgerufen. Der Product-Backlog-Eintrag, welcher beschreibt, dass sich der Kunde mit seinem Konto anmelden kann, kann so in zwei Teile aufgeteilt werden. Als Kunde kann ich mich mit meinem Konto anmelden. Dies beschreibt der Happy-Pfad. Als Kunde kann ich mein Passwort zurücksetzten, wenn die Anmeldung fehlschlägt. Dies beschreibt der Unhappy-Pfad. Weitere Möglichkeiten sind hier übersichtlich dargestellt. Strategie 5: Auflösen von Abhängigkeiten Obwohl Scrum Teams interdisziplinär sind, arbeiten sie doch in einem komplexen Umfeld, welches dazu führt, dass unbekannte Abhängigkeiten auftreten. Abhängigkeiten behindern Product Owner, das Product Backlog nach maximalem Wert zu ordnen, erhöhen das Risiko von Verzögerungen und können dazu führen, das Scrum Teams am Ende des Sprints kein nutzbares Inkrement erzeugen. Es gibt eine Vielzahl von Abhängigkeiten: Interne Abhängigkeiten: Product-Backlog-Einträge hängen voneinander ab. Beispielsweise, wenn Workflowschritte aufeinander aufbauen, wenn bestimmte Product-Backlog-Einträge Bestandteile eines Release sein müssen, oder wenn Product-Backlog-Einträge zusammenhängend einen größeren Nutzen liefern. Externe Abhängigkeiten: Product-Backlog-Einträge hängen von externen Faktoren ab. Die Einträge können von Geschäftsprozessen wie Freigabeprozessen oder Einkaufsprozessen abhängen. Sie können von Fremdsystemen abhängen, wenn die Arbeit technische Änderungen in einem Bereich des Systems erfordert, der außerhalb der Kontrolle des Scrum Teams liegt. Oder es wird die Expertise oder Unterstützung einer Person mit spezifischem Wissen benötigt. Scrum Teams machen Abhängigkeiten im Product Backlog frühzeitig sichtbar, um sie aufzulösen. Sie gehen dabei wie folgt vor. Nach Identifikation der Abhängigkeiten werden die Product-Backlog-Einträge mit Pfeilen so markiert, dass ersichtlich wird, wie die Einträge voneinander oder von externen Faktoren abhängen. Nachdem alle Abhängigkeiten im Product Backlog sichtbar gemacht sind, ergibt sich ein Graph, welcher Einsichten in die mögliche Abarbeitungsreihenfolge liefert. Diese Einsichten ermöglichen dem Scrum Team, Abhängigkeiten aufzulösen, indem sie Product-Backlog-Einträge zerkleinern, neue technische Lösungswege suchen, die ohne Fremdsystem auskommen, oder sich im Team fehlendes Wissen aneignen. Product Backlog Refinement ist essenziell Neue Erkenntnisse für die anstehende Arbeit zu gewinnen, diese im Backlog anzuordnen, zu schätzen, zu zerkleinern und bestehende Abhängigkeiten aufzulösen, hilft Scrum Teams und deren Stakeholdern fortlaufend, die Arbeit zu präzisieren, um ein gemeinsames Verständnis herzustellen. In Scrum wird diese Product-Management-Aktivität als Product Backlog Refinement bezeichnet. Sie ist essenziell, denn sie verringert das Risiko, am Ende des Sprint mit der Arbeit nicht fertig zu werden. Möchtest Du mehr erfahren? Hoffentlich war dieser Artikel nützlich für Dich. Wie man das Refinement durchführt, ist eines der vielen interessanten Themen, die in meinen Professional Scrum Trainings behandelt werden. Wenn du keinen neuen Beitrag mehr verpassen willst, dann abonniere meinen Newsletter, dort wirst du als Erster über neue Beiträge informiert. 👉 Hier geht zur Anmeldung.

Eine lineare, schrittweise Abfolge von Änderungen — in der Regel durchgeführt von funktional getrennten Abteilungen — ist völlig unvereinbar mit der Änderungsgeschwindigkeit und Komplexität moderner Softwareprodukte.

In jedem Professional Scrum Product Owner Training werden die gleichen 10 Fragen gestellt. Und das zu Recht! Das sind die Dinge, mit denen die Teilnehmer am meisten zu kämpfen haben.

Wie können Scrum Teams in ihrer Entwicklungsarbeit den Nutzer niemals aus dem Auge verlieren? Hier 3 einfache Praktiken, die sie von YouTube, LinkedIn, Microsoft lernen können.

Über 100 Jahre Industriezeitalter haben uns gelehrt, dass die Lieferung von Produkten den Erfolg eines Unternehmens bestimmt.

Wann ist das Feature fertig? Diese legitime Frage, die Stakeholder im Sprint Review stellen und welche regelmäßig Mitglieder des Scrum Teams zusammenzucken lässt, sollte jeder erfahrene Product Owner beantworten können.