User Story
Heute geht es auf unserer Reise in die Agilen Welten & Methoden weiter, denn das Thema ist User Story.
Heute geht es also um Agiles Anforderungsmanagement. Natürlich geht es auch darum, was sind Dinge, wie wir sehen, die man mit User Stories falsch und auch richtig machen kann?
Diese Folge auf YouTube: https://youtu.be/hrPK8VmWEAs
Anwendergeschichte
Übersetzt bedeutet User Story, dass es um eine Anwendergeschichte geht. Das ist es auch wirklich. Es geht also um eine Geschichte oder Anforderung aus Sicht des Anwenders. Hier erwischen wir auch wieder ein Agiles Prinzip. Nämlich den Kunden (in dem Fall den Anwender) in den Mittelpunkt zu stellen. Also nicht aus Sicht des Produktes unsere Anforderung zu beschreiben, sondern aus Sicht der Anwenderin.
Unsere höchste Priorität ist es, den Kunden durch frühe und kontinuierliche Auslieferung wertvoller Software zufrieden zu stellen. – 1. Agiles Prinzip für Softwareentwicklung | http://agilemanifesto.org
Stell Dir vor Deine Product Ownerin würde in der Kaffeeküche einer Anwenderin begegnen und die beiden würden darüber reden, was es aus ihrer Sicht an Weiterentwicklung am Produkt geben wird. Die Kundin würde beschreiben, was sie gern mit dem Produkt machen würde, wenn es diese Funktion denn hätte. Genau das ist eine User Story.
Diese User Zentriertheit bringt auch die erste große Unterscheidung zwischen User Story und Anforderung.
Benutzergruppen
Eine User Story enthält immer die Benutzergruppe, die diese am Ende verwenden möchte. Am besten kommt diese Story auch von dieser Gruppe oder wurde von der Product Ownerin während eines Gespräches aufgenommen. Damit ist sichergestellt, dass wir auch eine Gruppe von Menschen haben, die diese neue Funktion verwenden möchten und einen Mehrwert daraus ziehen.
Diesen Grundgedanken hat auch Jeff Sutherland in die Agilität mit seinem Buch „The Art of Doing Twice the Work in Half the Time“ gebracht hat.
In dem Buch geht es darum das Richtige zu entwickeln. Und was wäre da besser, als dies vom Anwender direkt zu erfahren, statt es ihm später zu verkaufen. Natürlich braucht es beides. Viele Anwender kommen oft nicht auf disruptive Ideen und gleichzeitig ist es eine sehr gute Grundhaltung, vom Anwender aus zu denken.
So können wir unsere Energie in die richtigen Produkte, im richtigen Ausmaß zur richtigen Zeit stecken.
Diese Kunden können uns auch genau erzählen, ab welchem Umsetzungsgrad sie bereits zufrieden sind und vielleicht auch Geld dafür bezahlen würden.
Mach die Hürde niedrig
Wenn Du kundenzentriert entwickeln möchtest, dann mach die Schwelle für den Anwender sehr niedrig um neue User Stories oder Anforderungen an das System stellen zu können. Ich habe das Gefühl viele Systeme machen es Menschen absichtlich schwer, damit sie nicht zu viele gute Anregungen bekommen und vielleicht auch noch etwas für ihre Anwender umsetzen…
Gute Anforderungen
„Aber ich bekomme doch keine guten Anforderungen, wenn ich den Kunden frage…“ – ja stimmt oft, aber führen diese guten Anforderungen auch gleichzeitig zu guten Produkten?
Die User Story ist super kurz und knackig und enthält bis zur Umsetzung, alles was wir brauchen. Wochen oder Monate lang eine perfekte Anforderung zu schreiben hilft und gerade im komplexen Bereich eher wenig und verzögert nur das Projekt. Die genaue Spezifikation einer Anforderung passiert im Planning 2 bis dahin reicht die User Story als kurzer Satz völlig aus.
Wir nennen die User Story also nicht nur anders, es ist wirklich etwas anderes als eine Anforderung um auch etwas anderes zu erreichen.
Template
Es gibt verschiedene Arten von Templates für eine User Story.
As a (role) I want (something) so that (benefit).
Im Internet finden sich verschiedene Quellen dazu. Sowohl Mike Cohn, als auch die UK Firma Connextra scheinen diese Form der User Story vorangetrieben zu haben.
Hierzu das Buch User Stories Applied: For Agile Software Development von Mike Cohn und Addison Wesley.
Gebräuchlich ist daher auf das Connextra Template zu referenzieren um diese Firma dafür in Erinnerung zu behalten.
Was macht das Template so besonders?
Es ist kurz und knackig. Wir schreiben aus Sicht einer Rolle. Nicht einer Persona.
Es wird beschrieben, was diese Rolle mit unserem Produkt tun möchte. Nicht die Lösung.
Vor allem wird auch der Nutzen dieser „Funktion“ beschrieben. Also welchen Nutzen hat diese Rolle / Anwender am Ende davon. Dies hilft Entwicklern dabei Entscheidungen zu treffen, die genau diesen Nutzen später erfüllen. Vielleicht auch durch ganz andere Realisierungen. Bei normalen Anforderungen wissen Entwicklerinnen oft nicht, wofür das Ganze geschaffen werden soll und haben daher oft gar nicht die Möglichkeit von der Anforderung abzuweichen.
In dieser Geschichte ist ausreichend viel Beschrieben um mit der Story arbeiten zu können. Genauer wird diese dann im Planning 2 durch ihre Subtasks beschrieben.
Mehr Details lohnen bis dahin nicht. Hier würden wir durch mehr Details auch Dinge vorweg nehmen, die wir eigentlich erst in der Entwicklung entdecken würden. Aus diesem Grund nutzen wir ja Agilität im komplexen Bereich.
Was gehört sonst noch rein?
Wir würden neben dem Templatesatz einer User Story noch folgende Dinge hinzufügen:
- eindeutige ID
- Titel / Überschrift
- Umsetzer / Ansprechpartner
- Akzeptanzkriterien
- Link
- StoryPoints
- Verfallsdatum / Mindestens haltbar bis
Bei explorativen User Stories werden die Akzeptanzkriterien häufig auch zu Abbruchkriterien.
Zusätzlich solltest Du noch markieren, dass es zu dieser User Story ein Gespräch mit dem Team gab. Also ein Refinement. Dies kannst Du auch darüber markieren, dass die Story geschätzt wurde und es damit Story Points gibt. Alternative wäre ein Haken oder ein Datum, an dem das Gespräch stattfand. Dies vermeidet, dass völlig unbekannte Stories für die Entwickler in den Sprint kommen. Der beste dieser Zustände wäre: Diese Anforderung erfüllt unsere Definition of Ready
Für Anforderungen ist dieses Gespräch oft nicht erforderlich. Dies liegt auch daran, dass wir Anforderungen eher im komplizierten oder klaren Bereich einsetzen.
Achtung, hier gibt es keinen einheitlichen Standard. Pack die Dinge in die User Story, die euch helfen.
Was macht eine User Story gut?
Bei guten User Stories sollte auf jeden Fall ein Nutzen dran stehen!
Dann empfehle ich Dir bei den Rollen aufzupassen. Ja, Product Ownerin ist auch eine Rolle und gleichzeitig hat eine User Story wie „Als Product Ownerin möchte ich …, weil ich das so will.“ wenig Mehrwert für die Kundin. Hier bitte noch einmal eine Schleife drehen und die Story aus Kundensicht betrachten. Also welchen Mehrwert hat unsere Kundin von dieser Story?
Eine richtig gute Story könnte zusätzlich ein Bild, ein Skribble oder MockUp enthalten, welches den Sachverhalt näher erklärt und daher einen tieferen Einblick in die Gedanken der Erstellerin gibt.
Bitte benutz den Template Satz und auch Akzeptanzkriterien.
Die Größe einer Story sollte dabei so gewählt sein, dass diese in einer Iteration (Sprint) auch ableistbar ist und damit zwischen zwei Plannings erledigt werden kann.
By the way wird eine User Story nicht mehr angepasst, wenn sie umgesetzt wird.
Wo beginnen?
Bei der Einführung kommt es auf das Team und die Scrum Masterin an. Also was fällt euch leichter?
Beispielsweise fielen Heny Schneiders Teams die Akzeptanzkriterien noch nicht so leicht, Janina Kappelhoffs dafür umso leichter. ID und Überschrift sollten aber immer gehen. Dann entweder Akzeptanzkriterien oder Template Satz. Der Rest, wie oben die Auflistung der Eigenschaften.
Cross-functional
User Stories sind anders geschnitten. Nämlich nicht nach Schicht, also dies ist eine BackEnd User Story oder diese beschreibt nur den Tortenboden, sondern nach Durchstich für den Anwender. Dies ist ein Stück Kuchen, welches ein Stück Tortenboden (Backend), Creme (Middleware) und Topping (FrontEnd) enthält.
Dies ist ein riesen Gedankensprung im Verhältnis zur Anforderung.
Get shit done,
Gefällt dir die Podcastfolge? Dann empfiehl sie gerne anderen weiter, z.B. indem du die Folge in deiner Story teilst. Wenn du magst verlinke @znip_academy_agile und wir teilen deinen Like mit unseren Hörern.
Du möchtest dich von uns in der Tiefe in eurem Veränderungsprozess begleiten lassen, eure größten Komplexitätsnester auflösen und die besten Teamtipps bekommen? Dann buch uns 😉
In der Podcastfolge erwähnte Folgen zur Vertiefung:
Connecte dich gerne hier mit uns:
