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

koehler@softwareforen.de

Softwareforen Leipzig GmbHP Hainstraße 16, 04109 Leipzig I www.softwareforen.de