Was ist eine User Story?
Eine User Story beschreibt eine Funktionalität, die für einen User oder Käufer eines Systems von (Mehr-)Wert ist. Sie setzt sich aus drei Bestandteilen zusammen:
- Einer schriftlichen Beschreibung der Story, die zur Planung und als Erinnerung verwendet wird.
- Gespräche über die Story, um die Details der Story herauszuarbeiten.
- Test oder Beispiele die
- Details vermitteln und dokumentieren
- festlegen, wann eine Story vollständig umgesetzt ist.
Warum braucht man User Stories?
Nachdem die Softwareindustrie unzählige Projekte in den Sand gesetzt hat (sei es aus Kosten, Termin oder Qualitätsgründen), haben sich ein paar „Best Practices“ durchgesetzt.
Eine dieser „Best Practices“ besagt:
Zerlege deine Arbeitspakete in möglichst kleine Einheiten.
Eine andere „Best Practice“ besagt:
Hör auf so zu tun, als wüsstest du alles schon im Voraus.
Was muss alles in einer User Story stehen?
User Stories versuchen die zwei erwähnten „Best Practices“ abzubilden. Also anstatt lange Texte zu verfassen, die beschreiben WIE sich ein System zu verhalten hat, konzentriert sich die User Story auf das WAS will der User und WARUM will der User das.
Da das WIE nicht beschrieben ist, muss man zwangsweise kommunizieren: Fragen klären, Verhalten festlegen etc. – 1:0 für die User Story!
Ermittlungsgehilfen sind die folgenden Fragen:
- Was müssen die Programmierer/Tester/Designer über die Story wissen?
- Was soll nach Beendigung der Story funktionieren?
- Gibt es Umstände unter denen diese Story anders abläuft?
- Was kann falsch laufen?
Wer erstellt denn eine User Story?
Der PO! Der PO? Die Antwort: it depends! Der PO ist zumindest der „Owner“ der User Stories. Er verantwortet ihren Wert und muss sie priorisieren. Doch erstellen kann sie theoretisch jeder. In der (guten) Praxis sieht das so aus, dass man User Stories gemeinsam erstellt. Mit 1-2 Experten, eventuell mit dem gesamten Team.
Warum sollte man das tun?
Weil man dadurch eine shared responsibility erzeugt. Jeder fühlt sich für die Story verantwortlich. Man steigert neben der Verantwortung auch das Wissen. Denn um bei einer Story mitzureden, muss man sich auch auskennen. Daher erzeugen wir ganz nebenbei ein „shared understanding“: vom Kunden, vom Problem, vom Kontext.
Was nützt so ein „shared understanding“?
Da gibt es viele Vorteile. Mein Hauptargument ist: ein Entwickler muss viel Entscheidungen treffen im Code. Nur ein kleiner Bruchteil davon findet sich in Akzeptanzkriterien wider. Je mehr Wissen er hat über den Kunden, das Problem, den Kontext, desto besser wird er seine Entscheidungen treffen.
User Stories zerkleinern – wie bekomme ich eine User Story „klein“?
Scrum und ähnliche agile Frameworks geben den Entwicklern die „Macht“ die Zerschneidung von neuen Anforderungen in kleine Pakete zu erzwingen. Eine höhere Abschätzung als 13 ist nicht erlaubt – schön oder?
Also was macht der liebe PO/Produkt Manger nun? Er überlegt sich wie er die User Story sinnvoll schneiden kann. Und interessanterweise scheitern viele daran. Meiner Erfahrung nach liegen die Gründe zu 30% an der mangelnden Kompetenz und zu 70% am mangelnden Willen.
Beim Willen kann ich nicht helfen, aber bei der Kompetenz – also welche Hilfsmittel gibt es um die Story zu „schneiden“?
- Happy Flow Szenarien ohne Error Handling oder Corner Cases
- Zuerst mach es gehend und dann hübsch
- Mach aus großen Akzeptanzkriterien eine eigene Story
- Splitte nach CRUD-Operation (anlegen, lesen, updaten, löschen)
- Fokusiere auf eine User Role oder Persona (zB Erstnutzer, Kassierer, Premium-Kunde, …)
- Nur ein simpler Algorithmus (z.b. nimm das erste Item) statt komplizierter Lösungen
- Kaufe eine Bibliotheken/Frameworks/… zu statt sie selbst zu entwerfen
- Suche nach „and“, „or“, Perioden, usw und simplifiziere
- Schränke den Support von Plattformen, Hardware, Betriebssystemen ein
- Ersetze
- „one“ statt „many“
- „batch processing“ statt „online processing“
- „manual process“ statt „automated process“
Beispiel:
As a user, i want to cancel a reserverion.
Akzeptanzkriterien:
- Verify that a premium member can cancel the same day without a free.
- Verify that a non-premium member is charged 10% for a same-day cancellation.
- Verify that an email confirmation is sent.
- Verify that the hotel is notified.
Aus dieser umfangreichen User Story können nun einige kleinere Stories extrahiert werden:
- As a premium site member, i can cancel a servation up to the last minute.
- As a non-premium member, i can cancel a servation up to 24 hours in advance.
- As a site visitor, i am emailed a confirmation about any cancelled reservation.
Was soll in den Acceptance Criteria stehen?
Meiner Erfahrung nach ist das von Team zu Team unterschiedlich. Die prinipzielle Idee ist nicht alle Details in die Story zu dokumentieren, sondern diese in Gesprächen zu erörtern und wenn notwendig in den Acceptance Criteria festhalten.
Die prinzipielle Idee der Akzeptanzkriterien besagt „Das muss funktionieren, damit die Story fertig ist“. Im besten Fall sind diese Kriterien durch automatisierte Tests abgedeckt.
Darf ich Akzeptanzkriterien im Laufe der Umsetzung ändern?
Natürlich! Je weiter die Umsetzung voranschreitet, desto mehr Informationen haben wir über das System, die Story und die Technologie. Neue Fragen werden auftauchen und diese müssen beantwortet und eventuell auch als Akzeptanzkriterium dokumentiert werden.
Was mache ich mit Use Case Beschreibungen oder anderen Artifakten?
Alles was dem Team hilft, ist erlaubt. Dh wenn das Team sagt „Ja, das benötigen wir“, dann wird es in der User Story verlinkt und ggf in den Akzeptanzkriterien verwiesen.
Was mache ich wenn das Team die Story aufgrund mangelndem Wissen nicht abschätzen möchte?
Erstmal: Tolles Team – es gibt nicht irgendeine Schätzung ab, sondern sagt ganz offen was sache ist: Wir kennen uns mit der Technologie / Framework / … nicht aus.
Ein tolles Mittel weiterzukommen ist der „Spike“. Ein „Spike“ ist eine Research User-Story, die time-boxed ist und das Ziel hat mit der neuen Technologie herumzuexperimentieren, damit die follow-up Stories abschätzbar sind.