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 (Product Goal) gesetzt: "Verkäufer:innen über eine mobile App dabei zu unterstützen adhoc Fragen von Kunden im Verkaufsraum besser beantworten zu können"
Zunächst sind wir mit folgenden Artefakten gestartet
Basierend darauf erstellte das Scrum Team einen Paper Prototype in Form von Wireframes. Insgesamt haben wir circa 1 Woche konzentriert an diesen Artefakten gearbeitet. 
In der nächsten Woche sind wir zu einem professionellen Usabilty Labor gefahren um dort Nutzer:innen zu treffen, die unsere Persona widerspiegelten. Sechs Nutzer:innen durchliefen jeweils eine Stunde lang diese Tests und gaben uns Feedback. Der Product Owner und ein Entwickler hielten das Feedback in Notizen fest. Insgesamt haben die beiden 15 DIN A4 Seiten handschriftlich festgehalten. Puh, das war viel Feedback!
Als wir zu Hause zurück waren, 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 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 alle Wireframes an einer Wand und die User Story Map an einer anderen Wand. (Inzwischen hatten wir die User Story Map digitalisiert und auf DIN A1 ausgedruckt.)
- Die Notizen mit dem Feedback wurden vorgelesen, und Mitglieder des Scrum-Teams schrieben Post-its und platzierten sie unter den entsprechenden Wireframes. Natürlich haben sie das Feedback soweit dabei konsolidiert, dass jede Information nur einmal vorkam. Daher konnte die Zahl der Post-its mit Feedback relativ überschaubar gehalten werden.
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 (siehe unten) und dann das Product Backlog entsprechend anzupassen.
Schliesslich erstellte das Scrum Team 12 neue Product Backlog Einträge, 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 Transparenz und damit das gemeinsame Verständnis über den Product Backlogs zu erhöhen.