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.