Folge 110 User Story

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,


Janina & Henry


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


Janinas Ultimativer OKR Guide


In der Podcastfolge erwähnte Folgen zur Vertiefung:


Team

Kahnemann

Product Ownerin

Komplex

Refinement

Kompliziert

Rollen

Team

Scrum Masterin



Connecte dich gerne hier mit uns:


LinkedIn


Instagram


YouTube


Facebook


Webseite


Facebook-Gruppe


The post Folge 110 User Story appeared first on Znipcast - für
gute Zusammenarbeit | Agile, Scrum, KanBan, Psychologie,
Teamentwicklung und NLP | Podcast der Znip Academy.