Wie erstellt man ein „gutes“ Product Backlog?
JIN-YOUNG LEE & ROOZBEH FAROUGHI
SEPTEMBER 2015
SCRUM in der Anwendung
– Pro...
2
SCRUM in der Anwendung – Product Backlog
Ziele und Inhalte des Tutorials
» Mit Hilfe dieses Tutorials sollen Methoden vo...
SCRUM in der Anwendung – Product Backlog
3
Einführung in Scrum, Product Backlog und
User Stories
4
SCRUM in der Anwendung – Product Backlog
Scrum in a nutshell
» Scrum ist ein Framework für
das Managen komplexer
Projekt...
5
SCRUM in der Anwendung – Product Backlog
Die Bedeutung des Product Backlogs
» Das Product Backlog ist eine Liste aller i...
6
SCRUM in der Anwendung – Product Backlog
Was ist eine User Story?
» User Stories beschreiben Anforderungen aus Sicht des...
SCRUM in der Anwendung – Product Backlog
7
Von der Idee zur User Story
8
SCRUM in der Anwendung – Product Backlog
Von der Idee zur User Story
Idee
Epic
User Stories
- Vage Formulierung eines ge...
9
SCRUM in der Anwendung – Product Backlog
Anforderung per Mail
» Eine Anforderung entsteht oftmals in
einem Gespräch. Die...
Epic
10
SCRUM in der Anwendung – Product Backlog
Epic als Word-Dokument (im Rahmen einer Analyse-Story)
» Ein Epic beschre...
Akzeptanz-
Kriterien
11
SCRUM in der Anwendung – Product Backlog
User Stories und Akzeptanzkriterien
» Die Akzeptanzkriter...
12
SCRUM in der Anwendung – Product Backlog
Abgeleitete User Stories (in Zusammenarbeit mit Team)
» Sobald das Epic von de...
SCRUM in der Anwendung – Product Backlog
13
Akzeptanzkriterien:
Methoden zur Validierung
SCRUM in der Anwendung – Product Backlog
Methodik für die Validierung der User Stories sowie der Akzeptanzkriterien
Das Vo...
15
SCRUM in der Anwendung – Product Backlog
DEEP Eigenschaften für die Überprüfung der Güte eines Product Backlogs
» DEEP ...
16
SCRUM in der Anwendung – Product Backlog
3 Cs Methode von Ron Jeffries
» Die Eine gute Merkhilfe für die Grundregeln ei...
17
SCRUM in der Anwendung – Product Backlog
Die INVEST-Kriterien nach Cohn
» Eine gute User Story erfüllt die sog. INVEST-...
18
SCRUM in der Anwendung – Product Backlog
Qualitätskriterien für die Dokumentation von Anforderungen
» Bereits im Jahr 1...
SCRUM in der Anwendung – Product Backlog
19
Zusammenfassung
SCRUM in der Anwendung – Product Backlog
Zusammenfassung
» Der Erfolg eines Scrum-Teams hängt von verschiedenen Faktoren
a...
Unsere Standorte
Niederlassung Darmstadt
Kasinostraße 60
64293 Darmstadt
Tel +49 61 51 – 78 90 0
Fax +49 61 51 – 78 90 23 ...
Nächste SlideShare
Wird geladen in …5
×

SCRUM in der Anwendung - Product Backlog

945 Aufrufe

Veröffentlicht am

In einem Mix aus Theorie und praktischen Erfahrungen beschreiben Jin-Young Lee (Senior Consultant) und Roozbeh Fahroughi (IT-Consultant) in ihrer Präsentation “How to create a product backlog final” wie man ein Product Backlog und die zugehörigen User Stories erstellt.

Veröffentlicht in: Business
0 Kommentare
3 Gefällt mir
Statistik
Notizen
  • Als Erste(r) kommentieren

Keine Downloads
Aufrufe
Aufrufe insgesamt
945
Auf SlideShare
0
Aus Einbettungen
0
Anzahl an Einbettungen
12
Aktionen
Geteilt
0
Downloads
15
Kommentare
0
Gefällt mir
3
Einbettungen 0
Keine Einbettungen

Keine Notizen für die Folie

SCRUM in der Anwendung - Product Backlog

  1. 1. Wie erstellt man ein „gutes“ Product Backlog? JIN-YOUNG LEE & ROOZBEH FAROUGHI SEPTEMBER 2015 SCRUM in der Anwendung – Product Backlog –
  2. 2. 2 SCRUM in der Anwendung – Product Backlog Ziele 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 Story 5. 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. 3. SCRUM in der Anwendung – Product Backlog 3 Einführung in Scrum, Product Backlog und User Stories
  4. 4. 4 SCRUM in der Anwendung – Product Backlog Scrum 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. 5. 5 SCRUM in der Anwendung – Product Backlog Die 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. 6. 6 SCRUM in der Anwendung – Product Backlog Was 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. 7. SCRUM in der Anwendung – Product Backlog 7 Von der Idee zur User Story
  8. 8. 8 SCRUM in der Anwendung – Product Backlog Von 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. 9. 9 SCRUM in der Anwendung – Product Backlog Anforderung 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. 10. Epic 10 SCRUM in der Anwendung – Product Backlog Epic 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. 11. Akzeptanz- Kriterien 11 SCRUM in der Anwendung – Product Backlog User 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. 12. 12 SCRUM in der Anwendung – Product Backlog Abgeleitete 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. 13. SCRUM in der Anwendung – Product Backlog 13 Akzeptanzkriterien: Methoden zur Validierung
  14. 14. SCRUM in der Anwendung – Product Backlog Methodik 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. 15. 15 SCRUM in der Anwendung – Product Backlog DEEP 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. 16. 16 SCRUM in der Anwendung – Product Backlog 3 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. » Conversation Jede 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. » Confirmation Um 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. 17. 17 SCRUM in der Anwendung – Product Backlog Die 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. 18. 18 SCRUM in der Anwendung – Product Backlog Qualitä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. 19. SCRUM in der Anwendung – Product Backlog 19 Zusammenfassung
  20. 20. SCRUM in der Anwendung – Product Backlog Zusammenfassung » 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
  21. 21. Unsere Standorte Niederlassung Darmstadt Kasinostraße 60 64293 Darmstadt Tel +49 61 51 – 78 90 0 Fax +49 61 51 – 78 90 23 0 Hauptsitz Bonn Kurfürstenallee 5 53177 Bonn Tel +49 228 – 76 36 31 0 Fax +49 228 –76 36 31 3 Niederlassung Bern Bridelstrasse 37 3008 Bern Tel +41 31 – 534 07 06 Fax +41 31 – 536 69 78 Niederlassung Neuss Hammfelddamm 6 41460 Neuss Tel +49 228 – 76 36 31 0 Fax +49 228 –76 36 31 3 Vielen Dank!

×