APM 9 – Backlog und User Stories

Anfang und Begrüßung

Buch von Mike Cohn: User Stories Applied.

Backlog

Wichtigste Liste für den Product Owner (mit Dingen, die das Entwicklungsteam umsetzen soll)  — Backlog hat eine Reihenfolge — Absolut Sortiert nach Priorität — Nicht etwa: vieles hat Priorität eins, der Rest eins plus — "Wenn alles die höchste Priorität hat, ist nichts wichtig" (Alex zitiert jemanden) — Das Wichtigste ist immer ganz oben — Dann guckt man gar nicht nach unten, da sammelt sich so der Schmodder" (Alex) — Verschiedene Backlogs: (Sprint Backlog — Product Backlog — Epic Backlog)  — Das Product Backlog sollte nicht zu wenig und nicht zu viele Einträge haben — Sprint Backlog ist nicht nur oberster Teil des Product Backlogs, sondern außerdem während des Sprints geschützt. — Atlassian Jira — Greenhopper / Agile — Unterschied zwischen Einträgen im Epic Backlog und Product Backlog sind (Größe / Umfang — Detailgrad der Beschreibung) .

User Stories

(in Wikipedia)  — Form: Als "Rolle" möchte ich "dies und das" um "zu erreichen" (Rolle: wer möchte etwas erreichen — Maßnahme: was möchte die Rolle erreichen — Grund: warum möchte die Rolle es erreichen)  — "Eine User ist das Versprechen, darüber zu sprechen" (Toby zitiert Jeff Patton) — Jeff Patton — User Story ist eine Aufforderung zur Kommunikation, damit ein gemeinsames Verständnis erreicht wird — Begriff Story vielleicht ungünstig, weil Geschichten keine Konversation sind — Extreme Programming (Kent Beck) (Card, Conversation, Confirmation)  — Trello.

Akzeptanzkriterien

Kriterien, anhand derer Entwickler erkennen können, ob sie auf dem richtigen Weg sind — Rahmenbedingungen und Randbedingungen — Nicht-Funktionale Anforderungen — Anzahl der Akzeptanzkriterien pro User Story ist nicht fest — Sven Röpstorff (Scrum in der Praxis)  — Blog von Sven über Produktmanagement (Akzeptanzkriterien können nicht vollständig sein) .

Epics und Themes

Größere Themenbereiche — User Stories sollten immer in einen Sprint passen (Epics können viele User Stories umfassen)  — Bilden eine Klammer und bieten Orientierung — Epics müssen nicht in einem Rutsch abgearbeitet werden.

User Story Mapping

Man hängt alle Epics nebeneinander, und jeweils darunter die dazugehörigen User Stories — User Stories sind auch hier nach Priorität sortiert — Schneiden von Releases — Sichtbarkeit von Abhängigkeiten — Buch dazu von Jeff Patton.

Discovery

(Füllen des initialen Backlogs durch Workshops)  — Entdeckungsreise mit Blick in alle Richtungen — Andere Einträge im Backlog als User Stories.

Schwierigkeiten bei Backlogs und User Stories

Backlog ist zu umfangreich, vollgestopft und unübersichtlich — Backlog zu kurz: Produkt schon fertig? — Backlog ist nicht sichtbar (innerhalb der Firma) — "Immer wenn wir was geschafft haben, schicken wir die User Stories an die Konkurrenz" (Alex zitiert jemanden) — Reporting durch das Backlog — "Was hilft denn Transparenz wenn keiner guckt" (Toby) — User Stories im Backlog mit dem Epic markieren zur Übersichtlichkeit — User Story ersetzt Anforderungsdokument, ist vollständig und final -> kein Gespräch — User Story ist zu knapp beschrieben (reicht nicht für den Start) — Backlog ist falsch sortiert: nicht nach Prio, sondern nach Epics — Zu viele oder zu wenige Rollen — "Als Nutzer möchte ich die Funktionalität bedienen, damit es funktioniert" (Toby) — Goldenen Mittelweg finden, wie so oft — Why-Teil ist optional, aber verhement wichtig.

Abschluss und Verabschiedung