Gute User Stories fallen nicht vom Himmel
Über den Lebenszyklus einer Anforderung im agilen Projekt
Dr. André KöhlerSoftwareforen Leipzig GmbH
Agil mit User Stories
Bildquelle: http://dilbert.com/
Warum US?• Weltweit und seit vielen Jahren bewährtes Mittel zur Anforderungsbeschreibung, insbesondere
in agilen Projekten.
Warum sind US gut?• Es wird ein konkreter Mehrwert aus Sicht des Anwenders beschrieben.
• Nach der Umsetzung hat die Software einen erhöhten Business-Nutzen.
Was ist eine US?• Eine kurze (ein Satz) Beschreibung einer Anforderung an ein Softwaresystem.
Wie sieht eine US aus?• Die US selbst wird mit einer
Satzschablone formuliert: Als <Rolle> möchte ich <Ziel>, so dass <Grund für das Ziel>.
• Kommunikation / weitere Beschreibungen.
• Akzeptanzkriterien.
User Stories (US) – Key Facts
Bildquelle: https://www.scrumwithstyle.com/courses/effective-user-stories
Wie schneidet man US?
• Immer vertikal durch die Schichten des Systems, so dass z.B. immer Frontend, Business Logik und Datenhaltung betroffen sind.
• Verschiedene Ansätze möglich. Z.B. nach Workflow, Geschäftsregel, Dateneingabe, Benutzerrolle, …
Wie geht man mit anderen Anforderungen um, die keine US sind?
• Alle funktionalen Anforderungen können als US beschrieben werden.
• Einige nicht-funktionale Anforderungen können ebenfalls US beschrieben werden, andere kann man als „Constraints“ des Projekts definieren.
Wer verfasst die US?
• Der Product Owner (PO) in Zusammenarbeit mit dem Team.
Wie bleibt der Überblick im Projekt erhalten?
• Durch eine Story Map.
User Stories – Key Facts
Bildquelle: https://manifesto.co.uk/user-story-mapping/
Wie groß soll eine US sein?
• Sie soll in einem Sprint zu erledigen sein.
Was macht man mit US, die zu groß sind?
• Diese bezeichnet man als „Epics“. Sie werden später in User Stories zerlegt.
Wie werden die US verwaltet?
• Im Product Backlog.
User Stories – Key Facts
Bildquelle: https://reqtest.com/agile-blog/how-to-build-your-product-backlog/
Was sind Akzeptanzkriterien?
• Ein Satz von Bedingungen, die erfüllt sein müssen, damit der PO die US abnimmt.
Warum sind Akzeptanzkriterien wichtig?
• Der PO wird gezwungen, so gut über seine Anforderung nachzudenken, dass er sie präzise und klar beschreiben kann.
• Sie beschreiben die Erwartungen des PO an die Umsetzung der US.
• Das Team versteht die Anforderung besser.
Was ist ein Akzeptanztest?
• Er beschreibt, wie die Erfüllung des Akzeptanzkriteriums getestet wird.
Wie umfangreich sollen Akzeptanztests beschrieben werden?
• Sie sind nie vollständig, sondern zeigen immer nur Schlüsselbeispiele auf.
Wer schreibt die Akzeptanzkriterien und die Akzeptanztests?
• Der PO, ggf. mit Unterstützung des Teams.
Akzeptanzkriterien – Key Facts
Bildquelle: http://rauru-block.org/agile-user-story-template/agile-user-story-template-unique-agile-acceptance-criteria-template-awesome-exelent-user-story/
Der Product Owner und die User Stories
Aufgabe des Product Owners allgemein• sicherstellen, dass ein möglichst großer Business-Nutzen
mit dem Softwareprodukt/-projekt erzielt wird
Aufgaben des Product Owners im Detail• Product Backlog initial bereitstellen und permanent
aktualisieren
• Gesamtheit der fachlichen Anforderungen überblicken, Konsistenz und Sinnhaftigkeit sicherstellen
• Vorbereitung / Führung der Meetings „Planning I“ und „Review“
• permanente Ansprechbarkeit für das Team, um z.B. Rückfragen zu beantworten oder Implementierungsalternativen zu entscheiden
• permanentes Testen des aktuellen Entwicklungsstands
… und wie es im wahren Leben aussehen kann
Und wie kommt der Product Owner zu User Stories?
Wie verhalten sich User Stories und Dokumentation zueinander?
Möglicher Lebenszyklus einer User Story – Teil 1
Theorie Praxis
Möglicher Lebenszyklus einer User Story – Teil 1
Theorie
Praxis
Was hilft uns, zu besseren User Stories zu kommen?
1. Zahl der Beteiligten aus den Fachbereichen so klein wie möglich halten
• Projektzuschnitte aus dem Demand- und Portfoliomanagement sind für die Umsetzung nicht immer die besten. Projekte sollten so klein geschnitten sein, dass man möglichst nur noch einen Ansprechpartner im Fachbereich hat.
2. Mitarbeit der Fachbereiche in notwendiger Quantität und Qualität sicherstellen
• „SLA“ mit Fachbereich schließen. Wer verantwortet das Backlog? Wie schnell muss auf Anfragen reagiert werden? Wann muss getestet werden? Fachbereiche müssen für Mitarbeit Kapazitäten einplanen. Wer mitreden will, muss auch zur Verfügung stehen.
3. Kommunikations- und Entscheidungswege so kurz wie möglich halten
• Abstimmungen möglichst in Meetings durchführen. Miteinander reden, anstatt Dokumente zu verschicken, die viele Rückfragen erfordern.
4. Fähigen Product Owner einsetzen
• Qualifizierung, Fähigkeiten, Befugnisse, Vollzeit
5. Alle betroffenen Personen in agiler Projektorganisation schulen.
Mitglieder
• Der Dreiklang der Agilität: Architektur, Innovationen & Festpreis
• Wie selbstorganisierte Teams produktiv werden – und was Agilität dazu beitragen kann
• Wie führt man einen Schwarm? – oder: Wie bringen sich Teammitglieder von selbst ein?
• Kontroverse: Agilität braucht keine Führung, oder?
• Testen & Requirements Engineering klassisch vs. Agile Entwicklung – Wie passt das zusammen?
Themenschwerpunkte der letzten Treffen Arbeitstreffen am 27./28. Sep 2018
• 10 Jahre Agilität – agile Transformation gestern und heute
Fachliche Leitung: Lisa Zenker Netzwerkknoten Unternehmensberatung GmbH
Dr. André KöhlerGeschäftsführerScrum Master & Agile Coach
T
E
+49 341 98 988 400
Softwareforen Leipzig GmbHP Hainstraße 16, 04109 Leipzig I www.softwareforen.de