Product Discovery im Scrum-Alltag

Habt ihr folgende Situation auch schon erlebt? Ihr kommt von einer Konferenz und habt Marty Cagan (oder jemand anderes) über Product Discovery sprechen gehört. Ihr habt gerade einen Workshop zu Design Thinking gemacht. Ihr habt Inkens und Wiebkes Artikel(serie) zum perfekten Product Design Sprint gelesen.

Kurzum, ihr habt gelernt, dass es wichtig ist, mit Nutzern zu sprechen, Interviews zu führen, Personas zu beschreiben, Story Maps zu erstellen, Prototypen zu bauen und diese iterativ zu testen. Und nun möchtet ihr gleich selbst in die nächste Product Discovery starten… Aber irgendwie passt Product Discovery nicht so richtig in euren Arbeitsalltag und den eures Scrum-Teams hinein.

Wie also könnt ihr vorgehen, damit das Erlernte auch wirklich in die Tat umgesetzt werden kann? Dieser Artikel soll ein paar Ideen aufzeigen, wie Product Discovery in die gängigen Scrum-Meetings integriert werden kann.

Retrospektive: Wie Product Discovery dem Team helfen kann

Die Retrospektive ist die perfekte Gelegenheit, das Thema Product Discovery anzusprechen und dem Team schmackhaft zu machen. Ihr habt mittlerweile ein gutes Bild davon, nun muss das Team von der Idee überzeugt werden. Erklärt dem Team, warum Product Discoveries wichtig sind, wie sie durchgeführt werden können – und vor allem auch, was das Team von Discoveries hat. Sieht das Team anschließend die Vorteile und den Bedarf für mehr und regelmäßige Discoveries? Wenn ja, diskutiert zusammen, wie man Discoveries mehr in den Arbeitsalltag integrieren kann.

Sprint Planning: Gemeinsam Stories oder Tasks für Discoveries definieren

Wenn ihr ein konkretes Thema für eine Product Discovery habt, stellt dem Team vor, was ihr vorhabt, wie lange das Ganze ungefähr dauern wird und diskutiert mit dem Team, wer wie dazu beitragen kann. Anschließend nehmt die Discovery in den Sprint Backlog bzw. auf das Taskboard auf. Hierzu kann entweder eine Discovery-Story, oder aber einzelne Aufgaben für die Discovery aufgenommen werden. Sprecht mit dem Team darüber, wer in welcher Rolle teilnehmen kann und überzeugt die Team-Mitglieder falls nötig davon, selbst einmal in einem User-Test zuzuschauen oder noch besser, selber Gespräche mit Nutzern zu führen – egal ob im User-Lab, auf der Straße oder sonst wo.

Plant auch für euch selbst ein, wie viel Zeit ihr für welche Discovery-Aufgaben aufwenden könnt – denn die anderen Aufgaben, die ihr als Produktmanager oder UX-Designer habt, erledigen sich (in der Regel) nicht von selbst.

Daily Standup: Der aktuelle Status der Discovery

Sobald ihr oder jemand aus dem Team an der Discovery-Story oder den Tasks arbeitet, sollte dies auch immer im Daily Standup besprochen werden. Was habt ihr am vorherigen Tag für die Discovery getan, was plant ihr für den heutigen Tag? Was behindert euch bei der Discovery? All diese Punkte sollten auch für Discovery-Tasks besprochen werden.

Hilfreich ist es hierbei auch, wenn die Discovery-Storys bzw. -Tasks mit am Taskboard aufgenommen werden. Hierzu können beispielsweise für Discoveries eigene Lanes am Board angebracht werden. Die Tasks können dann genauso wie für die anderen Stories jeden Tag ein Stückchen weiter durch die Spalten (in der Regel „ToDo“, „In Progress“, „Done“) geschoben werden.

Taskboard

Alternativ kann man für Discovery-Themen auch ein eigenes Board erstellen, auf dem die entsprechenden ToDos und Tasks separiert aufgehangen werden. Ist das normale Taskboard sowieso schon sehr voll, kann dies für mehr Übersichtlichkeit sorgen.

Was mit besonders daran gefällt, dass der Status der Discovery im Standup besprochen wird, ist die Tatsache, dass so auch Product Owner und / oder UX-Designer die Zeit erhalten, über ihre aktuellen Tätigkeiten zu sprechen – häufig erzählt sonst nur das Scrum-Team (also hauptsächlich die Entwickler), woran gearbeitet wird.

Eine Möglichkeit dabei ist, dass jeder einfach reihum sagt, woran er arbeitet, also Execution- und Discovery-Aufgaben vermischt werden. Eine Alternative kann sein, dass zunächst das Team über den Fortschritt bei der Execution spricht und anschließend dann die Discovery-Aufgaben besprochen werden. Letzteres erlaubt es Personen, die sich aktuell nicht für die Discovery interessieren, das Standup zu verlassen und sich der anderen Arbeit zu widmen.

Review: Vorstellung der Ergebnisse aus der Discovery

Am Ende des Sprints stellt das Team gewöhnlich die Ergebnisse vor – meist in Form eines Vorzeigbaren Produktinkrements. Warum sollten hier nicht auch die Ergebnisse der Discovery gezeigt werden? Seien es Research-Ergebnisse, eine Persona, eine Story Map oder sogar ein Prototyp. Zeigt und besprecht alles mit dem Team und den Stakeholdern. Sammelt Feedback und weitere Ideen ein. Schließlich ist dies genau der richtige Zeitpunkt, um noch auf Anmerkungen und Änderungswünsche der Stakeholder zu reagieren, bevor die User Stories ausdefiniert sind und das Feature in die Execution geht.

Retrospektive: Wie die Discovery weiter optimiert werden kann

Nach dem Sprint findet wieder eine Retrospektive statt. Nutzt die Zeit nicht nur, um die grundsätzlichen Themen zu besprechen und zu schauen, wie die Execution weiter optimiert werden kann, sondern besprecht auch, wie die Team-Mitglieder die Discovery empfunden haben, was gut lief und was weniger gut war. Schaut gemeinsam, wie die Product Discovery verbessert und wie sie noch mehr Teil des Arbeitsalltags werden kann.

Wenn das Team erst einmal gesehen und verstanden hat, wie viel Spaß Discovery machen kann und wie es sich noch viel früher bei der Produktentwicklung einbringen kann (nicht erst in der Umsetzung), dann werden alle Team-Mitglieder Ideen einbringen, wie man die Discovery weiter optimieren kann.

Product Discovery macht Spaß!

Wie sind eure Erfahrungen mit Product Discoveries im Arbeitsalltag? Habt ihr eure Teams schon erfolgreich dazu gebracht, sich mehr in der Product Discovery zu beteiligen? Dann teilt eure Erkenntnisse doch mit uns und den anderen Lesern!

Über Rainer Gibbert

Rainer ist Produktmanager mit großer Begeisterung für gute, Kunden-orientierte und wirtschaftlich erfolgreiche Produkte. Derzeit leitet er bei der Star Finanz GmbH in Hamburg den Privatkundenbereich und verantwortet die Weiterentwicklung der Software StarMoney. Zuvor war Rainer u.a. bei REBELLE als Head of Product, bei Fielmann Ventures als Senior Produktmanager sowie bei OTTO als Produktmanager im E-Commerce Innovation Center tätig und leitete das User Insights Team bei der XING AG.

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert.