Warum die Entdeckung und Validierung von Features im Refinement unverzichtbar ist – und wie du in 4 Schritten wertvolle Features identifizierst

Wie lässt sich die Arbeit von Scrum Teams verbessern?

Diese Frage beschäftigt nicht nur Scrum Master. Die Antwort lautet meist: Das Team braucht die richtigen Fähigkeiten. Die Zusammenarbeit mit Stakeholdern kann intensiviert werden. Die Mitglieder im Scrum Team sollten ihre Arbeitsweise stetig verbessern. Das Resultat: Scrum Master verbringen viel Zeit damit, Meetings wie Sprint-Reviews oder Sprint-Retrospektiven zu optimieren. Daran ist erst einmal nichts auszusetzen. Effektive Meetings sind wichtig – also Meetings, die alle einbeziehen und ihren Zweck erfüllen.

Allerdings wird dabei ein Aspekt oft vergessen:

Der Erfolg eines Scrum Teams wird maßgeblich von der Qualität des „Inputs“ für ihre Arbeit bestimmt. Was meine ich mit „Input“? Damit meine ich die Güte der Anforderungen, die Quantität der Ideen und das Verständnis für die Probleme der Nutzer.

Um diese Qualität sicherzustellen, führen Scrum Teams das Refinement des Product-Backlogs durch.

Der Scrum Guide beschreibt Refinement so:

„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. Diesen Transparenzgrad erlangen sie in der Regel durch Refinement-Aktivitäten.“

Hierbei sind zwei Punkte besonders wichtig:

• „Bereit“ bedeutet nicht nur technisch umsetzbar, sondern auch, dass die Arbeit wertvoll für unsere Kunden oder unser Unternehmen ist.
• Refinement beschreibt die Arbeiten an den Einträgen des Product-Backlogs, die vor dem Sprint-Planning passieren.

Diese beiden Punkte siehst du auch noch einmal in dieser Refinement-Grafik veranschaulicht:

2 häufige Irrtümer beim Refinement des Product-Backlogs

Wenn ich darüber mit unerfahrenen Scrum Mastern spreche, kommen in 9 von 10 Fällen sofort diese beiden Einwände:

• „Der Product-Owner ist dafür zuständig, dass die Arbeit der Entwickler Wert stiftet.“
• „Die Anforderungen kommen von den Kunden.“

Scrum Mastern ist wahrscheinlich kein Vorwurf zu machen. Leider wird das Refinement in vielen Lehrbüchern und Scrum Trainings im besten Fall als „technisches Konzeptionsmeeting der Entwickler“ beschrieben. Aktivitäten aus dem Produktmanagement haben dann darin keinen Platz.

Allerdings bin ich in beiden Punkten anderer Meinung.

Beginnen wir mit dem ersten:

Irrtum #1: Der Product-Owner ist allein für den Wert zuständig

Ich stimme zwar zu, dass laut dem Scrum Guide der Product-Owner für den Wert verantwortlich ist.

Allerdings ist „Verantwortlichkeit“ in Scrum nur ein Sicherheitsnetz, das dafür sorgt, dass kein Aspekt bei der Produktentwicklung übersehen wird. Der Scrum Guide möchte uns vor den möglichen finanziellen Konsequenzen für das Unternehmen warnen, wenn ein Team von Entwicklern einfach ohne Kundenkontakt irgendwas entwickelt. Ich bin der festen Überzeugung, dass es jeden im Team angeht, ob die Arbeit für den Kunden Wert stiftet oder nicht. Manche mehr, manche weniger. Aber wir sollten dies nicht nur in die Hände einer einzelnen Person legen. Dafür ist dieser Aspekt der Produktentwicklung einfach zu wichtig. Und ich bin auch davon überzeugt, dass Kreativität, gemeinsames Verständnis und Commitment besser erreicht werden, wenn das Team auf Augenhöhe zusammenarbeitet.

Die Kreativität, die in der Zusammenarbeit entsteht, ist die Quelle für Innovation.

Nun zum zweiten Einwand:

Irrtum #2: Die Anforderungen müssen vom Kunden kommen

Wer ist die Person, die am schlechtesten geeignet ist, ehrliches Feedback zu Ideen zu geben?

Laut dem Autor und Unternehmer Rob Fitzpatrick: deine Mutter. Denn sie wird in den meisten Fällen jede deiner Ideen großartig finden. Gleiches gilt für Ideen zu Features in der Produktentwicklung. Finden Nutzer eine Idee ganz toll, ist Vorsicht geboten. Deshalb lautet eine Weisheit im Produktmanagement, welche wahrscheinlich bereits auf Henry Ford zurückgeht: „Frage niemals die Kunden, was sie wollen.“ Wenn wir uns nicht zu sehr auf die Meinung der Nutzer oder Kunden verlassen können, was sollten Scrum Teams stattdessen tun?

Entdeckung und Validierung von Features zum Bestandteil ihrer Refinement-Aktivitäten machen.

Wenn du mir zustimmst, stellst du dir wahrscheinlich die nächste Frage:

Wie kann Entdeckung und Validierung im Refinement durchgeführt werden?

Ein Modell, um Produktentdeckung und Produktvalidierung zu beschreiben, ist der Doppel-Diamant.

Ursprünglich wurde dieses Modell von der britischen Regierung entwickelt.

Es besteht aus vier Phasen:

• Entdeckung des Problems
• Validierung des Problems
• Entdeckung von Lösungen
• Validierung der Lösungen

Betrachten wir die Phasen etwas genauer:

• Entdeckung des Problems: Als Erstes geht es darum, das Problem aus Unternehmenssicht zu formulieren. Dazu werden Stakeholder einbezogen und Markt- und Unternehmensdaten analysiert. In der Refinement-Grafik von oben würde diese Phase durch sehr vage Einträge im Product-Backlog wiedergegeben. Diese Einträge sind etwa „Erinnerungen“, Durchführung und Auswertung von Marktanalysen oder Ähnliches.
• Validierung des Problems: Nachdem ein Unternehmensproblem „entdeckt“ wurde, stellt sich die Frage: „Welche Bedürfnisse, Wünsche oder Probleme haben unsere Nutzer?“ In diesem Schritt geht es darum, das Problem auch aus der Perspektive der Kunden zu validieren. In der Refinement-Grafik könnte dies bedeuten, dass Nutzerinterviews oder Umfragen durchgeführt werden und der Eintrag im Product-Backlog mit diesen Informationen angereichert wird.
• Entdeckung von Lösungen: Ein gut verstandenes und validiertes Problem ermöglicht dem Scrum Team, Möglichkeiten zur Lösung zu betrachten. Hierbei trägt die vorab erfolgte Validierung des Problems dazu bei, dass das Team sich nur Gedanken zu wertvollen Problemen macht. Die Entdeckung von Lösungen kann hier vom Brainstorming bis hin zum Experimentieren reichen. In der Refinement-Grafik bedeutet dies, dass unterschiedliche Lösungsoptionen im Product-Backlog-Eintrag notiert werden. Vielleicht werden auch UX-Experten hinzugezogen, Nutzertests durchgeführt und diese Ergebnisse festgehalten.
• Validierung der Lösungen: Abschließend werden die Lösungsoptionen durch das Entwerfen, Durchführen und Lernen aus Experimenten validiert. Experimente bedeuten hier schlussendlich auch die Entwicklung, Lieferung und Messung von Features oder neuen Produkten. Die Schritte Entdeckung von Lösungen und Validierung der Lösungen wechseln sich ab und folgen der Truth-Curve. Mehr zur Truth-Curve kannst du hier lesen. In der Refinement-Grafik bedeutet dies, dass das Product-Backlog bereit für den Sprint ist und die Einträge auch im Sprint umgesetzt werden.

Diese vier Phasen kannst du nutzen, um den Refinement-Prozess in deinem Team in vier Schritten zu gestalten. Die Resultate der Refinement-Aktivitäten sollten immer im Backlog sichtbar sein. Einträge erhalten dadurch mehr Details, und ihre Reihenfolge im Backlog verändert sich. Je besser Problem und Lösung validiert werden, desto weiter wandern die Einträge nach oben. Einträge, die validiert werden, aber als weniger wertvoll angesehen werden, sollten nach unten wandern. Wertlose Einträge sollten unbedingt aus dem Backlog gelöscht werden, damit das Product-Backlog eine überschaubare Größe behält.

Zum Abschluss des Artikels möchte ich dir noch eine Liste möglicher Aktivitäten aus dem Produktmanagement mitgeben, die du im Refinement nutzen kannst. Ausführlich erklären und nutzen Boris und ich diese Aktivitäten im „Professional Product Discovery and Validation“-Training:

Ein Überblick über Produktmanagement-Aktivitäten, die das Product-Backlog-Refinement unterstützen

Beginnen wir mit der ersten Phase:

Entdeckung des Problems:

• Daten- und Markttrendanalyse: Diese Refinement-Aktivität konzentriert sich auf das Sammeln und Auswerten von Informationen über den Markt und die Mitbewerber. Ziel ist es, Informationen zu erhalten und Entscheidungen darüber zu treffen, welche „Opportunities“ es gibt und welche weiterverfolgt werden können.
• Interviews und Umfragen: Durch Interviews und Umfragen werden die Bedürfnisse, Erfahrungen, Verhaltensweisen, Motivationen und Einstellungen der (potenziellen) Nutzer des Produkts erfasst. Diese Methoden helfen, ein tieferes Verständnis für die Zielgruppe zu entwickeln, und ermöglicht es, Ideen, Probleme und Opportunities in Einklang mit den Nutzerbedürfnissen zu identifizieren.
• Customer-Journey-Mapping: Bei dieser Technik treten wir in die Fußstapfen der Kunden, um detailliert nachzuvollziehen, welche Erfahrungen sie machen, wenn sie mit dem Unternehmen, den Produkten oder Dienstleistungen interagieren. Durch das gemeinsame Erarbeiten einer Customer-Journey wird im Scrum Team ein einheitliches Verständnis über die Erlebnisse und Herausforderungen im Leben der Kunden geschaffen.

Validierung des Problems:

• Business-Problem-Statement: Diese Technik zielt darauf ab, die zentrale Problemstellung klar und prägnant in einem Satz zu formulieren. Durch diese Definition entsteht ein gemeinsames Verständnis des Problems sowohl im Scrum Team als auch mit den Stakeholdern, was die Grundlage für Lösungsoptionen bildet.
• „How might we“-Frage: Diese Frage stammt ursprüngliche aus dem Design-Thinking, lässt sich allerdings auch gut im Refinement nutzen. Dazu formieren wir das Problem als Frage: „How might we?“ Dabei deutet „How“ auf die Existenz mehrerer Lösungswege hin, das „Might“ schafft einen sicheren Raum für mögliche Ideen, und das „We“ betont die gemeinsame Problemlösung im Scrum Team.
• Kontext-Mapping: Mit dieser Frage-Technik erforschen wir den Kontext eines Problems, indem wir mit Fragen unterschiedliche Bereiche wie Umwelt, Wirtschaftlichkeit, Politik, Gesetzgebung, Nutzerbedürfnisse und technologische Risiken ergründen. Zur Beantwortung der Fragen interviewen wir Fachexperten, Stakeholder, Kunden und Nutzer.

Entdeckung von Lösungen:

• Brainstorming: Richtig eingesetzt ist Brainstorming eine effektive Methode, um in kurzer Zeit eine Vielzahl von Ideen zu generieren und die Auswahl an Alternativen zu erweitern. Es fördert die Zusammenarbeit im Team, hilft, komplexe Probleme anzugehen, und entfacht Begeisterung für das Thema, indem es Einsichten aus einer Gruppe mit breitem Fachwissen zusammenführt.
• Experimente oder Prototypen: Beim Entdecken von Lösungen geht es darum, mit minimalem Aufwand hilfreiche Erkenntnisse zu gewinnen, welche der Lösungsmöglichkeiten, die etwa im Brainstorming identifiziert wurden, weiterverfolgt werden soll. Dabei ist es sinnvoll, sich an der „Truth-Curve“ nach Giff Constable von Experiment zu Experiment weiterzuhangeln. So stehen finanzieller Aufwand und Erkenntnisgewinn zu jeder Zeit im Einklang.
• Spikes: Ein Spike ist eine zeitlich begrenzte Aufgabe in Scrum, die dem Team Klarheit darüber verschaffen soll, ob etwas technisch machbar ist. Spikes dienen dazu, Unsicherheiten zu reduzieren und fundierte Entscheidungen für die weitere Entwicklung zu treffen.

Validierung der Lösung:

• Feedback-Matrix: Mit einer Feedback-Matrix können Prototypen schnell und einfach getestet werden, wobei die Ergebnisse systematisch festgehalten werden. Sie ermöglicht eine strukturierte Erfassung von positiven Aspekten („Mir gefällt“), konstruktiver Kritik („Ich hätte mir gewünscht“), aufkommenden Fragen und neuen Ideen, die sich aus der Erfahrung ergeben. Ein Beispiel der Feedback Matrix findest du unten.
• Test-Canvas: Diese Methode dient der detaillierten Planung, Durchführung und Dokumentation von Tests. Hierbei kann es sich um Prototypen, aber auch um fertige Features handeln. Zunächst wird der Testablauf vorbereitet, inklusive der Definition von Testkriterien und der Rollenverteilung. Während der Testdurchführung werden Nutzer genau beobachtet und Feedback eingeholt. Abschließend werden die Ergebnisse, Zitate und Beobachtungen mit Fotos oder Kurzvideos dokumentiert und die wichtigsten Erkenntnisse zusammengefasst.
• Produktmetriken: Zum Beispiel bieten die Piraten-Metriken einen strukturierten Ansatz, um den Erfolg eines Produkts in fünf Phasen entlang der Kaufkette zu messen: Akquise eines Leads, Aktivierung des Leads, Kundenbindung, Ertrag und Empfehlung durch den Kunden. Diese Metriken helfen dabei, den gesamten Lebenszyklus eines Kunden zu analysieren und gezielt zu optimieren.

Diese 12 Techniken werden dir helfen, das Refinement des Product-Backlogs mit „Entdeckung und Validierungs“-Techniken aus dem Produktmanagement zu verbessern. Wenn du bei der Umsetzung Unterstützung suchst, dann wirf einen Blick auf das „Professional Product Discovery and Validation“-Training. Dort widmen Boris und ich diesem wichtigen Thema, welches in den meisten Scrum-Trainings keine Beachtung findet, einen ganzen Tag.