Wie erstellt man ein „gutes“ Product Backlog?

JIN-YOUNG LEE & ROOZBEH FAROUGHI

SEPTEMBER 2015

SCRUM in der Anwendung– Product Backlog –

2

SCRUM in der Anwendung – Product BacklogZiele und Inhalte des Tutorials

» Mit Hilfe dieses Tutorials sollen Methoden vorgestellt werden, wie man ein „gutes“ Product Backlog erstellt. Es wendet sich an:» Product Owner» Business Analysten» Scrum Team

» Das Tutorial beschäftigt sich mit den folgenden Punkten:1. Was ist Scrum?2. Was ist ein Product Backlog?3. Was ist eine User Story?4. Der Weg von der Idee zur User Story5. Welche Methoden zur Validierung gibt es?

» Die Erkenntnisse aus diesem Tutorial sind Best Practice Methoden, die im Rahmen von Kundenprojekten gewonnen und eingesetzt wurden.

3

SCRUM in der Anwendung – Product Backlog

Einführung in Scrum, Product Backlog und User Stories

4

SCRUM in der Anwendung – Product BacklogScrum in a nutshell

» Scrum ist ein Framework für das Managen komplexer Projekte

» Der Ansatz von Scrum ist empirisch, inkrementell und iterativ

» Bei Scrum gibt es:» definierte Rollen (Product Owner,

Scrum Master, Team)» einen geregelten Sprint-Ablauf

(Sprint Planning, Daily Stand-Up, Grooming, Review, Retrospective)

» Definierte Artefakte (Product Backlog, Sprint Backlog, Scrum Board)

Der Erfolg eines Scrum-Projekts hängt von einem idealen Zusammenspiel der genannten Faktoren für das jeweilige Scrum-Team ab

5

SCRUM in der Anwendung – Product BacklogDie Bedeutung des Product Backlogs

» Das Product Backlog ist eine Liste aller im Projekt bekannten User Stories. Das bedeutet nicht, dass die Liste vollständig ist. Vielmehr wird das Product Backlog mit der Zeit erweitert / aktualisiert sowie die enthaltenden User Stories detailliert.

» Mit Hilfe des Product Backlogs kann der Product Owner die umzusetzenden Features priorisieren und steuert somit sein Produkt und sein Team

» Je besser die Anforderungen im Product Backlog beschrieben sind, umso leichter ist die Abstimmungen mit anderen Stakeholdern und mit dem Team

» Die Güte eines Product Backlogs hat erheblichen Einfluss darauf, wie gut das Entwicklungsteam es abarbeiten kann

6

SCRUM in der Anwendung – Product BacklogWas ist eine User Story?

» User Stories beschreiben Anforderungen aus Sicht des Benutzers. Die Anforderung besitzt einen konkreten und sichtbaren Mehrwert für den Kunden. Sie ist bewusst kurz gehalten.

» Dabei wird jede User-Story auf eine Story-Card geschrieben.» Eine Vorlage für die Beschreibung einer User Story ist:

7

SCRUM in der Anwendung – Product Backlog

Von der Idee zur User Story

8

SCRUM in der Anwendung – Product BacklogVon der Idee zur User Story

Idee

Epic

User Stories

- Vage Formulierung eines gewünschten neuen Features (aus fachlicher Sicht)

- Entsteht oftmals im Gespräch zwischen verschiedenen Stakeholdern

- Ausformulierung der Anforderung - Dient als Diskussionsgrundlage mit anderen

Stakeholdern (z.B. Produkt Management, Architekten, POs anderer betroffener Teams)

- Dient als Diskussionsgrundlage mit dem Team

- Splittung des Epics in mehrere umsetzbare User Stories (Idee: 1 User Story = 1 Sprint)

- Kann vom Team geschätzt werden

Abstrakt

Konkret

9

SCRUM in der Anwendung – Product BacklogAnforderung per Mail

» Eine Anforderung entsteht oftmals in einem Gespräch. Diese Idee wird in verbaler oder schriftlicher Form (z.B. per Email) mitgeteilt

» Basierend auf den gelieferten Information beginnt für den Product Owner / Business Analysten die Analyse.

Idee

10

Epic

SCRUM in der Anwendung – Product BacklogEpic als Word-Dokument (im Rahmen einer Analyse-Story)

» Ein Epic beschreibt das gesamte Feature und dient als Diskussions-grundlage mit allen Stakeholdern und dem Team

» Für die Erstellung eines Epics eignet sich die Struktur einer User Story

» Ziel: alle Business-Anforderungen (vom Produkt Management) sollen – z.B. in einem Word-Dokument – beschrieben und abgenommen werden

11

Akzeptanz-Kriterien

SCRUM in der Anwendung – Product BacklogUser Stories und Akzeptanzkriterien

» Die Akzeptanzkriterien sind Richtlinien für das Team, was mit der User Story umgesetzt werden soll. Für den Product Owner handelt es sich um konkrete Abnahmekriterien.

» Im Sprint-Review stellt das Team die umgesetzte User Story vor, in dem sie i.d.R. jedes Akzeptanzkriterium durchgehen. Wurden alle Akzeptanzkriterien vorgestellt, kann der Product Owner die Story einfach abnehmen.

User Stories

User Stories

"As a <role>, I want <goal/desire> so that <benefit>"

Wann ist eine User Story abgeschlossen?

12

SCRUM in der Anwendung – Product BacklogAbgeleitete User Stories (in Zusammenarbeit mit Team)

» Sobald das Epic von der Fachseite abgenommen wurde, kann der Product Owner / Business Analyst mit der Aufsplittung in User Stories beginnen

» Dieser Prozess der User Story Erstellung ist i.d.R. ein Wechselspiel zwischen PO/BA und dem Team» PO/BA erstellen aus fachlicher Sicht User Stories» Beim Estimation entscheidet das Team, ob eine Story

zu groß/zu klein ist und splittet diese weiter oder legt Stories zusammen

» Die User Stories sollen im Product Backlog dokumentiert werden

» Eine User Story besteht aus» Beschreibung (= brief description)» Akzeptanzkriterien (= acceptance criteria)» Annahmen (= assumptions)» Abhängigkeiten (= dependencies)

User Stories

13

SCRUM in der Anwendung – Product Backlog

Akzeptanzkriterien:Methoden zur Validierung

SCRUM in der Anwendung – Product BacklogMethodik für die Validierung der User Stories sowie der Akzeptanzkriterien

Das Vorgehen für die Validierung:

1. Überprüfung der User Story und der Akzeptanzkriterien anhand der Fragen

2. Finden von Antworten anhand der gestellten Fragen

3. Überprüfung der User Story / Akzeptanzkriterien

4. Verfeinerung der User Story / Akzeptanzkriterien

» Fragen zur Validierung einer User Story: » Wer (Akteur, Rolle)» Was (Inhalt)» Warum (Wunsch, Pragmatik, Nutzen)

» Fragen zur Validierung von Akzeptanzkriterien:» Wann (Vorbedingungen des Systems, Geschäftsumfeldes)» Wie (Wie werden Inhalte (Struktur) verändert (Ablauf) | Aufsplittung der Kriterien nach Nomen und

Verben)» Wohin (Wohin gelangen Inhalte und in welchem Zustand)

14

15

SCRUM in der Anwendung – Product BacklogDEEP Eigenschaften für die Überprüfung der Güte eines Product Backlogs

» DEEP Eigenschaften für die Überprüfung der Güte eines Product Backlogs:» Detailed appropriately (Angemessen detailliert): Die Grundregel hierbei heißt: Je näher die Umsetzung eines Backlog- Items (also eines Elements aus dem Product Backlog) rückt, desto granularer sollte es aufbereitet sein:» Emergent (Sich entwickelnd): Ein Product Backlog ist nicht in Stein gemeißelt, sondern wird ständig gemeinsam von Product Owner und Team und mit Unterstützung des Kunden, der Anwender und weiterer Stakeholder weiterentwickelt. Dies erfolgt z.B. im Rahmen von sog. Backlog-Grooming-Workshops» Estimated (Beschätzt): Das Product Backlog sollte beschätzt sein. Für die Beschätzung gibt es zahlreiche erprobte Verfahren, etwa den Planning Poker oder das Estimation Game» Prioritized (Priorisiert): Die geplanten Aufgaben sollten stets priorisiert sein. Diese Priorisierung des Product Backlogs wird vom Product Owner vorgenommen und sichergestellt.

16

SCRUM in der Anwendung – Product Backlog3 Cs Methode von Ron Jeffries

» Die Eine gute Merkhilfe für die Grundregeln einer User Story» Card

User Stories sollen kurz und prägnant sein. Sie sollen in erster Linie an den Kundenwunsch erinnern und die wichtigsten Punkte, die mit dem Team vereinbart wurden, festhalten. Viele agile Software-Entwicklungsteams verwalten Stories und Tasks offline, z.B. in Form eines Taskboards. Die Kundenwünsche werden dann auf Karteikarten festgehalten. Es sollte damit nicht mehr Platz als der auf der Karte verfügbare benötigt werden, um dem Team klarzumachen, was mit der Umsetzung der Story erreicht werden soll. Reicht der Platz nicht aus, ist die Story in der Regel zu groß oder wird zu umfangreich dokumentiert. Über die Card hinaus werden Informationen über den Wunsch in Form der Konversation mit dem Team abgestimmt.

» ConversationJede Story wird zwischen dem Kunden und dem Team mindestens einmal besprochen. Der Austausch über die Story wird als sehr wichtig erachtet. Es reicht nicht, auf einer Karte die Anforderungen festzuhalten und dem Team “durch einen Türschlitz” zuzuschieben. Stories werden in der Regel sogar mehrmals besprochen, z.B. während der Grooming- und Estimation-Sessions und oftmals auch noch im Sprint-Planning. Die mündlichen Absprachen werden manchmal begleitet durch zusätzliche Dokumente, wie etwa Vorlagen in einem Projektwiki oder Mockups.

» ConfirmationUm einen Nachweis zu haben, ob die Stories in der gewünschten Form implementiert wurden, werden für jede Story Akzeptanzkriterien festgehalten. Der Kunde hält dafür vor Beginn der Umsetzung einer Story die zentralen Kriterien fest, nach denen die Abnahme der Story später erfolgen soll. Durch die Implementierung von Akzeptanztests kann die Erfüllung der Akzeptanzkriterien sichergestellt werden.

17

SCRUM in der Anwendung – Product BacklogDie INVEST-Kriterien nach Cohn

» Eine gute User Story erfüllt die sog. INVEST-Kriterien. INVEST steht dabei für:» Independent: Eine Story ist unabhängig von anderen Stories. Eine Story darf nicht davon abhängen, dass zuerst eine andere Story umgesetzt werden muss.» Negotiable: User Stories sind kein geschriebenes Gesetz. Kunden und Entwickler besprechen und präzisieren sie gemeinsam. Während der Kunde also die Funktionalität kurz und grob beschreibt, werden die Details mit den Entwicklern zusammen ausgearbeitet.» Valuable: Die Stories sollten einen erkennbaren Mehrwert liefern. Ansonsten gibt es keinen Grund, sie vorzuhalten. Der beste Weg zu wertvollen Stories ist der, sie vom Nutzer selbst schreiben zu lassen.» Estimatable: Eine Story muss so überschaubar sein, dass die Entwickler die Umsetzung der Anforderung beschätzen können. Zudem müssen die Entwickler natürlich über die entsprechenden fachlichen und technischen Kompetenzen verfügen.» Small: Über den konkreten Umfang von User Stories muss letztlich das Team entscheiden. Stories können „zu groß“ und „zu klein“ sein. Als grobe Regel gilt: Die komplette Umsetzung einer Story soll mindestens einen halben Personentag und maximal zehn Personentage erfordern.» Testable: Die Tests bilden den Maßstab dafür, ob eine Story erfolgreich abgeschlossen wurde oder nicht. Daher muss die Testbarkeit zwingend gewährleistet sein.

18

SCRUM in der Anwendung – Product BacklogQualitätskriterien für die Dokumentation von Anforderungen» Bereits im Jahr 1998 hat das Institute of Electric and Electronic Engineers (IEEE) den Standard IEEE 830 definiert. Die im Standard IEEE

830 formulierten Kriterien sind:» Korrekt: Die Anforderungen sind von den verantwortlichen Anforderungsstellern geprüft und verabschiedet.» Eindeutig:

Interpretationsfrei formuliert, sie definieren eindeutig was gewünscht ist und können nicht in unterschiedlicher Weise verstanden werden.

» Vollständig: Durch den Anforderungssteller ist sichergestellt, dass die Formulierung nicht nur korrekt, sondern auch vollständig ist. Hier dürfen keine Aspekte weggelassen werden.» Konsistent: Die Beschreibung ist so durchgeführt und geprüft worden, dass einzelne Anforderungen nicht automatisch andere Anforderungen in Frage stellen und nicht bekannte weitere Änderungen erforderlich machen.» Bewertet (Priorität /Aufwand): Formulierte Anforderungen sind vom Anforderungssteller priorisiert. Sie sind mit einer Wichtigkeit versehen und haben eine erste grobe Aufwandsschätzung.» Prüfbar: Zu jeder Anforderung sind so genannte »Akzeptanzkriterien« formuliert, die aussagen, unter welchen Bedingungen die Anforderung durch den Anforderungssteller abgenommen wird.» Modifizierbar / granular: Die Anforderungen sind so granular formuliert, dass eine Änderung möglich wäre, ohne dass andere Anforderungen betroffen wären.» Verfolgbar: Die Formulierungen müssen so durchgeführt werden, dass eine Nachvollziehbarkeit und Verfolgbarkeit gewährleistet wird. Vom Wunsch eines Stakeholders bis zur Projektplanung und zur Realisierung und Abnahme sollte die Anforderung verfolgbar sein. Dies wird z. B. durch die Zuordnung eindeutiger Nummern pro Anforderung grundsätzlich ermöglicht.» Gültig und aktuell: Der Anforderungssteller hat die formulierten Anforderungen aktuell zu halten.

19

SCRUM in der Anwendung – Product Backlog

Zusammenfassung

SCRUM in der Anwendung – Product BacklogZusammenfassung

» Der Erfolg eines Scrum-Teams hängt von verschiedenen Faktoren ab. Eines dieser Faktoren ist das Vorhandensein und die Qualität des Product Backlogs.

» In der Lehre wird immer wieder erklärt, wie ein Product Backlog auszusehen hat und welche Kriterien es zu erfüllen hat. Die Erstellung ist in der Realität oftmals gar nicht so einfach. » Gibt es bereits eine Spezifikation, KANN die Ableitung des Product

Backlogs einfacher sein (muss es aber nicht).» Beginnt man von Null an, braucht es seine Zeit, bis man für das jeweilige

Product und Scrum-Team einen gangbaren Weg gefunden hat.» Somit gibt es kein Patentrezept für die Erstellung eines Product

Backlogs. Das Tutorial konnte aber hoffentlich dennoch eine praktische Anwendung zeigen.

20

Unsere Standorte

Niederlassung DarmstadtKasinostraße 6064293 DarmstadtTel +49 61 51 – 78 90 0Fax +49 61 51 – 78 90 23 0

Hauptsitz BonnKurfürstenallee 553177 BonnTel +49 228 – 76 36 31 0Fax +49 228 –76 36 31 3

Niederlassung BernBridelstrasse 373008 BernTel +41 31 – 534 07 06Fax +41 31 – 536 69 78

Niederlassung NeussHammfelddamm 641460 NeussTel +49 228 – 76 36 31 0Fax +49 228 –76 36 31 3

Vielen Dank!