Habt Ihr das auch schon erlebt? Da kommen so viele Informationen zusammen, dass man

den Wald vor lauter Bäumen nicht mehr sieht? 

Lasst mich eine Geschichte aus dem echten Leben erzählen, wie ich als “Coach” einem Scrum Team helfen konnte genau dieses Problem zu überwinden.

Das Scrum Team hatte sich ein neues strategisches Ziel gesetzt eine mobile App für Verkäufer:innen anzubieten, damit diese adhoc Fragen von Kunden im Verkaufsraum besser beantworten können. 

Zunächst sind wir gestartet mit folgenden Artefakten

Basierend darauf erstelle das Scrum Team einen Paper Prototype in Form von Wireframes. 

Nach insgesamt einer intensiven Woche Arbeit, sind wir zu einem professionellen Usabilty Labor gefahren um dort von einer Agentur organisierte Nutzer:innen zu treffen, die unsere Persona widerspiegelten. Sechs Nutzer:innen durchliefen jeweils eine Stunde lang diese Tests und gaben uns Feedback. Die Entwickler:innen und der Product Owner hielten das Feedback in Notizen fest. 

Zu Hause standen wir vor der herausfordernden Frage: „Wie können wir diese enorme Menge an Feedback in das Product Backlog integrieren und alle Mitglieder des Scrum-Teams auf den gleichen Stand bringen?“ 

Das war wirklich eine harte Nuss zum Knacken! Wir haben haben folgenden Ansatz genutzt, der sich als sehr hilfreich herausstellte. In einem zweistündigen Workshop mit dem gesamten Scrum Team durchliefen wir folgende Schritte:

Wir platzierten die User Story Map an einer Wand und alle Wireframes an einer anderen Wand. 
Die Notizen mit dem Feedback wurden vorgelesen, und Mitglieder des Scrum-Teams schrieben Post-its und platzierten sie unter den entsprechenden Wireframes. 

Dann habe ich das Scrum Team gebeten, das Feedback zu überprüfen und wie folgt zu kategorisieren:

Gelber Punkt: UX ändern
Blauer Punkt: Terminologie ändern
Kein Punkt: neue Geschichte für die User Story Map

Anschließend aktualisierte das Scrum Team die User Story Map und entschied, welche Geschichten ein vernünftiges erstes Ergebnis für den Benutzer liefern würden. Es wurde eine entsprechende Linie auf der User Story Map gezogen, wie das folgende Bild zeigt. 

Am Ende des Workshops gab ich dem Scrum Team die „Hausaufgabe“, die digitale Version der User Story Map anzupassen und dann das Product Backlog entsprechend anzupassen.

Schlußendlich erstelle das Scrum-Team 12 neue Product Backlog Items, und hatte ein klares Verständnis über das beabsichtigte Ergebnis für das erste Release. 

Die User Story Map war der Schlüssel zum Erfolg, da es dem Scrum Team dabei half, die Sichtbarkeit und das gemeinsame Verständnis des Product Backlogs zu erhöhen.

Habe ich Euer Interesse geweckt? Kommt zu einem meiner Trainings. Insbesondere unterrichte ich auch den neuen Kurs “Professional Scrum Product Backlog Management Skills™ Training”. 

Mein aktuelles Kursangebot findet Ihr wie folgt: LINK

 

 

 

 

 

 

Leave a Reply