Diese Seite setzt Cookies ein, um das Nutzerlebnis zu verbessern. Durch Klick auf "OK" erklärst Du Dich damit einverstanden. Mehr dazu gibt es unter Datenschutz.

OK

User-Story-Qualität verbessern – eine kleine Hilfestellung

Eine schlechte Userstory: keine relevanten Informationen aber Druck.

Eine schlechte Userstory: keine relevanten Informationen aber Druck.

Diesmal geht es um die User-Story-Qualität. Im Artikel „User-Stories schreiben – Wer darf das eigentlich?!“ gehe ich auf die Frage ein, wer Stories eigentlich schreiben darf und wer für sie verantwortlich ist. Dabei nehme ich das Team ausdrücklich nicht aus. Das wird zwar nicht jedem gefallen, ist jedoch unabdingbar. Denn eine User Story als „promise for a conversation“ bindet alle beteiligten Seiten – alle sind für sie verantwortlich.

Die Frage hier ist jedoch etwas früher angesiedelt: Was schreibt man in eine Story als Ausgangspunkt rein? Was muss gegeben sein, damit das Team überhaupt eine Möglichkeit hat sich einzubringen? Denn auch hier gibt es Mindestanforderungen. Ein Beispiel.

User-Story-Qualität: ungenügend

Hin und wieder stolpert man über ein Juwel – und manchmal hat man eine ganze Diamantenader an der Hand. Man sieht Stories von diesem Kaliber hier:

Als User brauche ich einen Button mit der Aufschrift „hier klicken!“ Dieser Button soll möglichst prominent platziert werden und den User auf eine neue Seite führen. Das Projekt ist mit dem Vorstand abgesprochen und soll asap umgesetzt werden. Fragen bitte an meine Vertretung – ich bin jetzt erstmal 3 Wochen im Urlaub.

Titel? „Verbesserung der Performance!“ – Eh klar …

Zugegeben, hier ist das Ganze auf die Spitze getrieben. Gleichzeitig ist es leider manchmal nicht so weit von der Wirklichkeit weg.

Wenn ich als PO oder Produktmanager regelmäßig mit einer solchen User-Story-Qualität beim Team aufschlage, brauche ich mich nicht wundern, wenn irgendwann alle abschalten.

Wo liegt nun das Problem?

Der Titel der User-Story

Schauen wir uns zunächst nochmal den Titel an. Der lautet „Verbesserung der Performance.“ Das ist vermutlich eine gute Idee. Aber es lässt einen Aspekt offen. Welche Performance soll denn gesteigert werden? Die mit der die Seite im CMS generiert wird? Oder die Vermarktung der Seite? Oder die Usage durch die Nutzer?

Hier ließe sich leicht Abhilfe schaffen:

  • Seiten durch CMS schneller generieren
  • Vermarktungserlöse von Seite XY steigern
  • User zum Weiterklicken animieren

Auch diese Storytitel erklären das Thema nicht komplett – müssen sie aber auch nicht. Sie fassen kurz und knapp die Stoßrichtung der Story zusammen und bilden so den Rahmen für die Konversation.

Das Problem beschreiben, nicht die Lösung

Es ist der User-Story-Qualität auch abträglich, wenn ich das falsche darin beschreibe. Wenn ich nicht das Problem definiere, sondern gleich in einen Lösungsansatz hin springe. Eine Abkürzung, die nur all zu verführerisch ist – man will ja schnell auf den Markt:

Als User brauche ich einen Button mit der Aufschrift „hier klicken!“ Dieser Button soll möglichst prominent platziert werden und den User auf eine neue Seite führen.

So. Steht alles genau drin. Können wir nun endlich anfangen? Nein.

Was soll damit erreicht werden? Wer jetzt sagt „der User soll auf eine neue Seite kommen“, der hat es nicht verstanden. Die Frage ist wozu soll der User auf eine neue Seite gelangen? Was hat der User davon? Welchen Mehrwert bieten wir dem User damit? Wie wäre es stattdessen mit etwas wie

Als User möchte ich, nachdem ich einen Artikel gelesen habe, weitere Artikel und Bildergalerien zum gleichen Thema angeboten bekommen. Damit ich mich weiter in das Thema einlesen kann und es besser verstehe / mehr darüber weiß.

Das Problem ist also dass ein User mehr über ein Thema wissen will. Aber dass ihm dieser content nicht zugänglich ist. Wenn ich dem User nun mehr Inhalte zum gleichen Thema anbiete – bspw. in Form einer Linkliste (okay, okay, die würde man grafisch ordentlich aufbereiten um das Maximum raus zu holen), löse ich das Problem. Ich mache dem User die Inhalte zugänglich.

Ist doch gleich viel besser und gibt der Konversation zusätzlich Leitplanken. Team und PO wissen beide, was die (angenommene) Intention des Users ist und konzentrieren sich so auf zielführende Lösungsvorschläge. Wenn ein User mehr zum Thema lesen will, dann sollte ich ihm nicht die meist geklickten Artikel des Tages anbieten. Das zieht vermutlich nicht.

Daraus lässt sich schon einiges für die Implementierung ableiten.

Bei Schwierigkeiten können auch die 5 Warums helfen, eine Methode um Ursache-Wirkungszusammenhänge zu entdecken. Das muss man nicht zwingend in der Form durchexerzieren. Vom Wesen her ist es aber eine gute Idee. Einfach mal weiter nach dem „Warum?“ fragen – mitunter kommen da sehr hilfreiche Dinge ans Licht. Zurück zum Thema …

Auch für’s Business ist die Beschreibung des Problems wichtig. Ich habe dann gleich eine Hypothese formuliert, die ich überprüfen kann. Denn wenn die User Inhalte zum gleichen Thema nicht klicken, ist meine Annahme, dass der User mehr zum Thema möchte, vielleicht nicht richtig. Dann muss ich diese Erkenntnis verwenden um mein weiteres Vorgehen anzupassen. Vielleicht biete ich den Usern nun doch die populärsten Artikel des Tages an …

Man kann also sagen, dass eine (ordentliche) Problembeschreibung auf allen Seiten Gewinner produziert: als Teammitglied weiß ich worum es geht und kann mich konstruktiv einbringen. Als PM / PO bekomme ich schneller einen passenden Lösungsvorschlag. Dieser wird schneller umgesetzt (Stichwort „time to market“) und ich habe auch gleich die Basis für mein Controlling an der Hand.

Die Perspektive

Wenn mein Titel lautet „Vermarktungserlöse von Seite XY steigern“, dann wird auch die umformulierte Story, wie sie oben steht, nicht viel helfen. Es heißt zwar „User-Story“, aber nicht immer ist die Formulierung aus Sicht des Users elegant:

Als User möchte ich dazu animiert werden eine weitere Seite aufzurufen, damit ich dort über Werbemittel über verschiedene Produkte und Partnerangebote informiert werde.

Ernsthaft?!

So schön die Form „Als XY möchte ich 1,2,3 damit ich dies und das …“ auch ist. Wenn man sich zu sehr verbiegen muss um ins Korsett zu passen, läuft was falsch. In dem Fall ist es einfach die Rolle. Und wenn der Vermarkter ein Problem hat das ich lösen soll, dann sollten wir das auch direkt so sagen. Das macht die Sache einfacher:

Als Vermarkter möchte ich mehr Gelegenheit haben, dem User Werbemittel und Partnerangebote zu zeigen um so die Vermarktungserlöse zu steigern.

Direkter geht es fast nicht. Das Problem ist umrissen – ich möchte mehr Gelegenheit Werbemittel und Partnerangebote zu platzieren. Der need und die Motivation sind einfach nachzuvollziehen ohne dass man ums Eck denken muss. Das Team kann nun verschiedene Lösungsansätze formulieren und PO / PM und Team können die Story weiter drehen und sich auf die vielversprechendste Lösung (am billigsten, am schnellsten, am schonendsten etc.) verständigen.

Wenn ich eine Story aus der richtigen Perspektive schreibe, dann lässt sie sich in der Regel auch einfacher formulieren und ist leichter verständlich. Das verschlankt den Prozess und beschleunigt den Fortschritt.

Weniger Rauschen, mehr Signal

Bei Schaubildern und Diagrammen gibt es die data-ink-ratio (Edward Tufte). Ihr zufolge soll der größte Teil der Tinte auf dem Diagramm Daten repäsentieren. Auf User-Stories gemünzt hieße das so etwas wie: Der größte Teil des Texts sollte sich um die Problembeschreibung drehen und relevante Informationen enthalten. Zieltermine, Kontaktdaten etc.

Das Projekt ist mit dem Vorstand abgesprochen und soll asap umgesetzt werden.

Wow. Das ist der data-ink-ratio nur sehr eingeschränkt förderlich. Ich für meinen Teil gehe davon aus, dass wir nicht an unwichtigen Dingen arbeiten …

Okay. Der Satz oben mit dem Vorstand ist nicht gut. Was wäre besser?

Das Projekt muss bis Ende des Monats umgesetzt werden, damit wir bei der monatlichen Abrechnung keine Probleme bekommen.

Dankeschön. Mehr?

Fragen bitte an meine Vertretung – ich bin jetzt erstmal 3 Wochen im Urlaub.

Das ist tatsächlich wichtig. Gut dass das drin steht. Dann kann ich gleich mit der Urlaubsvertretung ins Refinement Meeting gehen.

Je weniger Text ich brauche um das Problem zu umreißen, umso besser. Alle können die Story schneller erfassen und wenn sie aktualisiert werden muss – und das wird der Fall sein – ist es leichter, wenn ich weniger Text umschreiben muss.

Was tun um die User-Story-Qualität zu verbessern?

Abgesehen von Dingen wie den INVEST-Kriterien kann man also in Kürze sagen:

  • auf den Titel des Story achten – keine mehrdeutigen Begriffe verwenden, einfache aber präzise Sprache verwenden. Kurz und plakativ.
  • das Problem beschreiben – welcher need besteht? Welches Problem soll gelöst, welcher Mehrwert geschaffen werden? Warum / wozu braucht es das?
  • die richtige Perspektive wählen – die Form „als XY möchte ich 1,2,3“ allein erklärt noch gar nichts. Wichtig ist die richtige Perspektive zu wählen, so wird das Problem nachvollziehbar und widerspruchsfrei (man denke an User die laut User-Stories Ads sehen wollen …)
  • alles raus schmeißen, das keine direkte Relevanz für das Thema hat – sich auf das wesentliche konzentrieren, Ablenkungen minimieren.

Hier geht es um inhaltliche Fragen, die lassen sich nicht durch Pflichtfelder in Eingabemasken klären. Hier müssen PO und PM verstehen, welchen Hebel sie haben und wieviel Potenzial darin steckt. Je schneller desto besser.

Wie man mit „technischen Stories“, oder wie auch immer man die nennen mag umgeht, zu einem späteren Zeitpunkt. Denn auch das ist kein Ding der Unmöglichkeit.

Verwandte Artikel

Schönen Mittwoch!