Ein Experiment: Geh in dein Backlog und scanne alle User Stories nach Titel. Frag dich: „Ist das eine Problembeschreibung oder schon eine vorgeschlagene Lösung?“
Als ich das mit einem meiner Kunden gemacht habe, war die verblüffende Antwort:
Nicht eine einzige Problembeschreibung vom Nutzer existierte im Backlog (das Backlog hatte circa 150 Einträge, was für sich genommen schon ein Problem ist).
Selbst wenn die Beschreibung die Problembeschreibung des Kunden enthalten würde – warum verstecken wir sie? Allein die Lösung im Titel zu lesen, beeinflusst die Entwickler und hindert sie daran, selbst zu denken.
Das hat Auswirkungen, die meiner Meinung nach niemand will:
- In kleinere Teile zu schneiden ist viel schwerer, wenn du vor einer Lösung stehst. Wie soll man eine Lösung slicen?
- Menschen werden konditioniert, einfach die vorgeschlagene Lösung umzusetzen
Beides führt nicht dazu, dass Teams sich für die geschaffenen Lösungen verantwortlich fühlen.
Ein Beispiel aus dem echten Leben (und es gibt viele davon):
Der PO hat mit Nachdruck darauf gedrängt, dass das Team eine bestimmte Story umsetzen und innerhalb von 10 Tagen liefern soll. Die Story enthielt das Kundenproblem überhaupt nicht – nur eine Lösung. Das Team fing an zu jammern, weil es nahezu unmöglich war, das rechtzeitig zu schaffen. Und ja, es gab eine Deadline.
Also habe ich angefangen zu fragen:
ICH: Was ist das Bedürfnis des Kunden, oder was hat der Kunde als sein Problem beschrieben?
PO: Oh, er will nur sehen, wie das Redesign der UI aussieht.
ICH: Würde ein Screenshot oder Mockup reichen?
PO: Nein, der Kunde will sehen, wie man mit der UI interagiert.
ICH: Will er selbst klicken, oder würde eine Aufnahme vom Bildschirm eines Entwicklers reichen?
PO: Eine Aufnahme wäre okay.
DAS TEAM: Ok, die Aufnahme könnt ihr in den nächsten 3 Stunden haben.
Statt ein ganzes Team zum Verzweifeln zu bringen, indem man es eine fast unmögliche Sache rechtzeitig machen lässt, hat ein Entwickler kleine UI-Änderungen gemacht und aufgenommen, wie er sich durchklickt – zack, fertig!
Das Problem für das Team war, das Backend zum Laufen zu bringen – der UI-Teil war tatsächlich sehr einfach.
Kunde und PO waren glücklich: Statt 10 Tage warten, waren es jetzt 3 Stunden.