Die "perfekte" User Story

Eine Rolle in einer User Story sollte immer ein legitimer Endnutzer des Produkts sein. Also der BE-Admin der Bestellungen verwalten muss. Der Redakteur der neue Inhalte einstellen muss. Die Shopperin etc. pp... Wenn eine Rolle, z.B. die Shopperin, ein zu breites Spektrum abbildet, kann man auch einen Schritt weiter gehen und mehrere Personae entwickeln, die immer einen Teil abdecken. Z.B. die Gelegenheisshopperin Sophia, 32 Jahre alt, Einzelhandelfachverkäuferin, die sich gerne von Angebot zu Angebot treiben lässt bevor sie sich entscheidet. Zumeist reicht uns eine grobe Rolle. Für Konzeptionen kann eine Persona allerdings sehr hilfreich sein. Für Rollen eher ungeeignet – bzw. sollten auf jeden Fall vermieden werden – sind Entwickler, Designer, POs, ausser sie sind legitime Endnutzer des Produkts. Entwickelten wir eine IDE so wäre der Endnutzer-Entwickler eine legitime Rolle. Eine nicht legitime Rolle zu verwenden ist ein erster "Smell" für eine schlechte User Story.



Feature

Ein Feature ist das, was gemacht werden soll, um den folgenden Grund zu erreichen. Hier sollte auch immer nur das "Was" stehen, niemals das "Wie". Wie etwas gemacht wird entscheidet innerhalb der Rahmenbedingungen immer das Team.

Grund

Das "Warum". Eigentlich der wichtigste Teil und damit auch der am meisten vernachlässigte. Manchmal habe ich das Gefühl, dass der erste Grund der einfällt auch gleich genommen wird. "Als Kunde möchte ich einen Slider, damit ich Produkte platzieren kann." Dient der verwendete <Grund> nur als Rechtfertigung für das <Feature> so ist dies ein weiterer "Smell" für eine schlechte User Story. An dieser Stelle sollte stehen, was man sich davon verspricht, was man damit erreichen will, oder was das <Feature> bewirken soll. Ich gestehe ein, dass dies mühsame Arbeit ist, gerade dann wenn man selbst nur als Mittler zum Kunden die Information zum Team weiterträgt und noch viele andere Dinge zu erledigen hat.

Oft wird es einfach nur hingenommen, was der Kunde sagt. In diesem Zusammenhang wird meiner Meinung nach in Agenturen zu wenig nachgefragt, warum ein Kunde etwas will. Manchmal stellt sich heraus, dass das gewünschte <Feature> ein Workaround von früher ist, der so wieder gemacht werden soll, aber der eigentliche Grund, also das wirkliche "Warum", ließe sich evtl. kostengünstiger und vor allem ganz anders umsetzen. Techniken, um auf das "Warum" zu kommen sind die "5 Why's" oder "Impact Mapping". Darüber hinaus gibt es auch sicherlich weitere Möglichkeiten, um das "Warum" zu erfragen.

Wenn das Team weiß "Warum" etwas gemacht werden soll, kann es dies besser umsetzen. Zumal das Team nur dann die Möglichkeit hat ein noch besseres <Feature> zu finden was dem "Warum" besser hilft verwirklicht zu werden.

Card - Conversation - Confirmation

Card

Eine User Story soll so kurz sein, dass diese auf eine Karte passt. Also keine verschachtelten Sätze über 5 Zeilen wie ich sie schreibe sondern kurz und knapp. Das mag, wenn man nur eine physikalische Karte hat, durchaus ein pragmatischer Ansatz sein. Tatsächlich ist es etwas leichter zu verstehen, wenn es kurz und knapp ist. Deswegen sind z.B. einfache Hauptsätze verständlicher – wenn auch nicht unbedingt so schön zu lesen. Da jedoch meist digitale Issues als Karten verwendet werden, haben wir meist zu viel Platz, um die User Story kurz zu halten.

Conversation

Die Konversation findet in einem Schätzmeeting statt. Es ist unerlässlich, dass der PO oder ein hinreichend informierter Stellvertreter daran teilnimmt. Kommen Fragen auf, können diese sonst nicht sofort geklärt werden und die Schätzung verschiebt sich wieder. Dadurch entsteht Verschwendung. Die Konversation dient dazu, dass alle ein gemeinsames Verständnis für die User Story bekommen. Alle nötigen Informationen die User Story erfolgreich umzusetzen werden festgehalten. Idealerweise spricht man nicht nur mit dem PO, sondern auch mit allen anderen Stakeholdern und Endbenutzern. Zumindest mit einem Vertreter jeder Gruppe.

Confirmation

Ist man sich durch die Konversation einig geworden, kann man die UAK festhalten. Diese müssten – oder sollten – nicht zwangsweise vorgegeben sein. Besser ist es die UAKs gemeinsam im Team (DevTeam und PO) während der Konversation aufzuschreiben. Sie dienen am Ende zur Gewährleistung der korrekten Umsetzung. Ein UAK sollte so ausführlich wie nötig sein. Das kann von einem Stichwort bis zu einem Oberflächentest alles bedeuten. Je kritischer ein <Feature> ist, umso detaillierter sollten die UAKs sein.

Hier finden Sie mehr Informationen zum Thema Card - Conversation - Confirmation

I.N.V.E.S.T.

Independent - Unabhängig

Am schlimmsten ist es wenn User Storys so stark voneinander abhängen, sodass sie im Wechsel bearbeitet werden müssen. Wenn dann noch mehrere Personen an den User Storys arbeiten ist das Chaos und die Verschwendung vorprogrammiert. Einseitige Abhängigkeiten sind weniger schlimm aber immer noch zu vermeiden. Wenn erst eine User Story fertiggestellt werden muss bevor eine andere begonnen werden kann – sehr häufig bei Trennung von Funktionalität und Design – führt das ebenfalls zu Wartezeiten. Ist eine User Story für sich alleine umsetzbar so generiert sie den Wert mit Ihrer Fertigstellung.

Negotiable - Verhandelbar

Eine Story kann bis zu ihrer Umsetzung jederzeit umgeschrieben werden. Sobald neue Informationen verfügbar sind, muss die User Story angepasst werden. Im Scrum wird die User Story nicht mehr angepasst wenn sie in den Sprint genommen wurde. Ich denke man kann in Absprache auch danach noch Änderungen vornehmen, solange die User Story dadurch nicht eine komplett andere wird. Wichtig ist hier die Absprache zwischen den Entwicklern und dem PO.

Valuable - Wertvoll

Jede User Story schafft durch sich selbst einen Wert. Es ist also keine andere User Story notwendig um erst einen Wert zu erreichen. Es mag sein dass User Storys im Zusammenspiel einen noch größeren Wert schaffen, aber jede alleine schafft einen Wert für einen Endnutzer.

Estimable - Bestimmbar

User Storys müssen abschätzbar sein, um sie entweder einplanen zu können oder (im Support) grobe Kosten kommunizieren zu können. Ist eine User Story nicht abschätzbar, ist sie entweder zu groß und sollte geschnitten werden, oder es wurde noch nicht verstanden um was es geht.

Small - Klein

Eine User Story muss klein genug sein um sie innerhalb eines Sprints umsetzen zu können. Bei der Größe einer User Story gibt es mehrere Punkte zu beachten. Sie sollte (1) groß genug sein, um nicht zu viel Overhead zu erzeugen. Sie muss (2) klein genug sein, um sie vernünftig abschätzen zu können. Sie muss (3) groß genug sein, um einen Wert zu erzeugen und sie muss (4) klein genug sein, um den Wertschöpfungsfluss nicht zu bremsen.

Testable - Testbar

Kurz und Knapp: Kann man eine User Story nicht testen, kann man sich nicht sicher sein, ob sie richtig umgesetzt wurde.

Hier finden Sie mehr Informationen zum Thema I.N.V.E.S.T

Minmum viable product - kleinstes brauchbares Product

Das "Minimum Viable Product" umfasst alle Schichten die notwendig sind um die User Story zu erfüllen. Von der Datenbank über Schnittstellen ins Backend – einschließlich der (gestylten) Anzeige im Frontend. Betrifft eine User Story nur die Funktionalität nicht aber die Anzeige, so wäre eine weitere User Story notwendig mit der dann beide erst ihren Wert erzeugen. Das "klassische" Schneiden in BE und FE um den Entwicklern (vermeintlich) die Arbeit zu erleichtern oder weil die User Story sonst zu groß wäre, verstößt also gegen dieses Prinzip.

Hier steckt m.E. aber viel mehr drin. Das kleinste brauchbare Produkt ist zum einen durchgängig durch alle Schichten, aber auch klein genug, um eine erste Version zu haben. Diese kann in der Regel relativ schnell fertiggestellt und vom Endnutzer geprüft werden, um schnell neue Informationen zu bekommen. Wo kann etwas verbessert werden? Wo fehlt etwas? Wo funktioniert etwas nicht? Wird das Produkt überhaupt angenommen? Und und und...

Konzipieren wir gleich etwas bis ins letzte Detail bevor wir etwas umsetzen, können wir auch erst nach der Umsetzung feststellen, ob das was wir erreichen wollten zum einen erreicht wurde und ob es die Mühe überhaupt Wert war. Machen wir aber eine kleine Basis-Version vorab können wir mit geeigneten Messwerten feststellen, ob es sich lohnt mehr dahingehend zu investieren oder ob es nicht besser wäre doch eine andere Idee zu verfolgen.


Do's and Dont's (Liste lässt sich beliebig fortführen)

  •  + Schreibe eine User Story und nimm Dir dafür die nötige Zeit.
  •  + Schreibe die User Story kurz und verständlich.
  •  + Schreibe mindestens ein Kriterium (mit dem Team) mit dem die User Story am Ende getestet werden kann.
  •  + Die User Story ist mit allen Beteiligten besprochen worden. (Dev, PO, Kunde, Endnutzer)
  •  - Kopiere die Mail vom Kunden 1:1 in die Description.
  •  - Die wichtigste Information ist nur in entsprechenden Anhängen zu finden.
  •  - Die wichtigen Dokumente sind nur per Link aufrufbar.
  •  - Verwende die Rolle "Entwickler".
  •  - Schreibe Deine User Story so lange wie möglich damit auch ja jegliche Information in der User Story enthalten ist, sodass auch niemand auf die Idee kommt es könnte etwas fehlen und so möglicherweise die User Story nicht richtig umgesetzt wird und somit die ganze Arbeit umsonst war.

Andere Arbeit andere Form?

Ja. Eine User Story eignet sich gut für ein <Feature> ist jedoch weniger geeignet für simples Maintenance. "Als Kunde möchte ich den neuen Text lesen, weil der alte ist nicht mehr gültig." Hier eignet sich eher – wie bei Bugs – das Schema "Ist - Soll - Zustand". Ebenso für viele andere Kleinigkeiten, die in der Regel in kürzester Zeit machbar sind (Farbänderungen, Pixelverschiebungen, Übersetzungen, etc.).

Nun zur "perfekten" User Story

1. Wir müssen unterscheiden, ob wir es mit einem tatsächlichen <Feature> zu tun haben oder, ob es sich um einen Bug oder eine kleine Tätigkeit handelt.

a) Es ist ein Bug

b) Es ist eine kleine Tätigkeit, entweder die IST-Soll Beschreibung oder rein informativ.

c) Es ist ein <Feature>

2. User Story schätzen, umsetzen...

Fazit

Ich habe schon einige User Storys gesehen. Schlechtere und Bessere. Storys in denen schon stand, wie diese umzusetzen seien. Storys bei denen so wenig Information drin stand, sodass man nicht einmal wusste was gewünscht ist. Copy&Paste aus Kundenmail. Nur die Mail als Anhang, nicht einmal eine Beschreibung. Und, und, und... Ich glaube, dass wenn man eine User Story so schreibt, dass sie alle (oder zumindest die meisten) oben genannten Kriterien erfüllt auch besser umgesetzt wird und viel seltener dazu führt wieder zurück zu kommen. Ist sie außerdem noch so formatiert, dass man schnell zu ihr Zugang findet und sich nicht durch einen Fließtext kämpfen muss, benötigt man weniger Zeit um sie zu erfassen und richtig einzuschätzen. Wenn zu Guter Letzt auch noch wichtige neue Informationen nicht nur in den Kommentaren irgendwo dazwischen stehen sondern mit in die Beschreibung aufgenommen werden...

Neueste Posts

Die größten Akquisitionen von Google, Amazon und Apple und einige Learnings daraus!
Neue Ausgabe des eStrategy-Magazin verfügbar 360 Stories – ein Spiel für Teams Die B2B E-Commerce Pyramide
Digital Storytelling - ein Kurztrip in die Kreativität und wieder zurück

Archiv

Dezember November Oktober September August Juli Juni Mai April März Februar Januar
Dezember November Oktober September August Juni Mai April Februar Januar
Dezember November Oktober September August Juli Juni März Februar
Oktober September August Juli Juni Mai April März Januar
Dezember November Oktober September August Juli Mai April Februar
November Oktober September April Februar
Dezember September Juni Mai Februar Januar
Juli Mai April März Februar Januar
September August Juli März
Oktober September Juli Juni Mai März Februar
Februar

Kategorien

E-Commerce Unternehmensmeldung Online-Marketing Magento Commerce Neos TYPO3 SEO SEA Usability Digitale Transformation Agile Projektentwicklung Corporate Web Analytics Künstliche Intelligenz Mobile Marketing Social Media Veranstaltungen Research & Development

Unser Herz schlägt online -
Deins Auch?


Wir stellen uns jeden Tag neuen Heraus-forderungen des Online-Business – immer auf der Suche nach spannenden Lösungs-ansätzen und sinnvollen Technologien. Eine Vielzahl namhafter Kunden vertrauen auf das Online Know-how „Made in Kolbermoor / Rosenheim und München“. 

Lust auf TechDivision? Hier geht zu unseren Stellenanzeigen

eStrategy Magazin


Erfahren Sie mehr zu den Themen E-Commerce, Online-Marketing, Mobile, Projektmanagement, Webentwicklung und E-Recht in unserem kostenlosen Online-Magazin.

Jetzt herunterladen!

Whitepaper:
Agiles Projektmanagement


In unserem kostenlosen Whitepaper versuchen wir Basiswissen und Erfahrungen aus vielen Jahren täglicher Projekt- und Unternehmenspraxis zu vermitteln, mit denen Sie die Anforderungen des Arbeitslebens von Heute besser bewältigen können.

Jetzt herunterladen!

Autor

Haben wir Ihr Interesse mit unserem Blog geweckt?

Wir sind der richtige Partner für anspruchsvolle Projekte im Bereich E-Commerce, Corporate Web, Consulting und Online-Marketing. Sprechen Sie mit uns!

Autor

Josef Willkommer Geschäftsführer / CMO