Dr. Sven Strobel (PO, Scrum Team AV-Portal)
Leipzig, 20. März 2019
BibTag 2019
Das TIB AV-Portal setzt auf
das agile Management-
Framework Scrum
Basics & Lessons Learned
Agenda
1. Entwicklung des TIB AV-Portals
2. Was ist Scrum?
3. Rollen in Scrum
4. Ereignisse in Scrum
Seite 3
Entwicklung des TIB AV-Portals // av.tib.eu
Entwicklung
 TIB und HPI / Yovisto
 Online seit Frühjahr 2014
Management der Entwicklung
 2011 - 2015: Wasserfallmodell
 2015 - 2017: Integration agiler Methoden
 2018: Umstellung auf Scrum
Profil
 Freies Portal für wissenschaftliche
AV-Medien aus Technik & Natur-
wissenschaften
Agenda
1. Entwicklung des TIB AV-Portals
2. Was ist Scrum?
3. Rollen in Scrum
4. Ereignisse in Scrum
Seite 5
Was ist Scrum?
 Scrum ist ein Management-Rahmenwerk zur Entwicklung
komplexer Produkte
 Scrum besteht aus definierten Rollen, Ereignissen, Artefakten
sowie den Regeln, die sie miteinander verbinden
 Produkt, Prozesse & Methoden werden in Scrum regelmäßig
überprüft und angepasst (empirische Prozesssteuerung) (*)
(*) Schwaber, Ken & Sutherland, Jeff (2013). The Scrum GuideTM, the Definitive Guide to Scrum: The Rules of the Game,
scrum.org.
Seite 6
Sprint-Zyklus in Scrum
Sprint
4 Wochen
Daily
Scrum
Priorität
Product
Backlog
Sprint
Backlog
Product
Increment
Agenda
1. Entwicklung des TIB AV-Portals
2. Was ist Scrum?
3. Rollen in Scrum
4. Ereignisse in Scrum
Seite 8
Rollen in Scrum
Product Owner
 Priorisierung der
Anforderungen
 Abnahme des
Product Increment
Entwickler
 Umsetzung der
Anforderungen
Scrum Master
 Verantwortlich für
Einhaltung der Scrum-
Regeln
 Beseitigung von
Hindernissen
Entwicklerteam
Scrum Team
Agenda
1. Entwicklung des TIB AV-Portals
2. Was ist Scrum?
3. Rollen in Scrum
4. Ereignisse in Scrum
Seite 10
Ereignisse in Scrum
 Der Sprint ist der Container für alle übrigen Ereignisse in Scrum:
 Sprint Planning
 Daily Scrum
 (Backlog Grooming)
 Sprint Review
 Sprint Retrospective
Überprüfung & Anpassung
von Produkt, Prozessen und
Methoden
Seite 11
Sprint
 Container für alle (übrigen) Ereignisse in Scrum
 Feste Timebox: 2 - 4 Wochen
 Ziel: Herstellung eines auslieferbaren Produktinkrements
Seite 12
Sprint Planning
 Wer: Product Owner & Entwickler
 Was sind die umzusetzenden Anforderungen?
 Wie sind sie priorisiert?
 Wie werden diese Anforderungen realisiert?  Tasks
 Ergebnis: Sprint Backlog
Start
Seite 13
Dos & Don’ts – Sprint Planning
 Plane maximal 2 Stunden pro Woche des Sprints für das Sprint
Planning ein
 Bereite das Product Backlog (Priorität, Detaillierung & Schätzung) gut
vor  Sprint Planning effektiver
 Berücksichte die durchschnittliche Velocity des Teams (z.B. der letzten
3 Sprints) sowie Urlaube, Dienstreisen & Feiertage
 Plane nicht den perfekten Plan. Konkretisiere die Dinge im Laufe des
Sprints: Welche Aufgabe kommt zuerst?, Wer macht das?, Wie lange
dauert das?...
 Breche zu große Backlog-Einträge auf mehrere kleine Einträge herunter
(z.B. per Obergrenze: 13 Pts.)
Seite 14
Daily Scrum
 Wer: Entwickler, (Product Owner)
 Timebox: 15 min
 Zweck: Tägliche Überprüfung, Sychronisierung & adaptive Planung
 Was habe ich gestern getan?
 Was werde ich heute tun?
 Gibt es Hindernisse?
Seite 15
Dos & Don’ts – Daily Scrum
 Führe das Daily Scrum täglich durch (am besten vormittags)
 Halte die Timebox von 15 min ein
 Alle erscheinen pünktlich
 Entwickler führen das Daily Scrum selbst durch – ohne Lead
 Nimm als PO an den Dailies teil
 Nutze ein Board für die aktuellen Tasks und aktualisiere es im Daily
Scrum
 Bespreche aufkommene Probleme in einem Anschlusstreffen mit den
dafür relevanten Beteiligten
Seite 16
Backlog Grooming
 Kein offizielles Scrum-Ereignis
 Wer: Product Owner & Entwickler
 Input: Product Backlog
 Detaillieren, Priorisieren & Schätzen der Backlog-Einträge
 Vorbereitung der nächsten Sprints
 Entfernen von Backlog-Einträgen, die nicht mehr relevant sind
Seite 17
Dos & Don’ts – Backlog Grooming
 Führe pro Sprint mind. 1 Backlog Grooming durch
 Überprüfe das Product Backlog und organisiere es kontinuierlich neu
 Ziel: das Team erledigt die wichtigsten Arbeiten für das Produkt
 Detailliere und schätze hochpriorisierte Backlog-Einträge; niedrig-
priorisierte Einträge können vage bleiben
 Bereite die nächsten beiden Sprints vor
 Gruppiere zusammengehörige Backlog-Einträge in Epics
Seite 18
Sprint Review
 Wer: Scrum Team & Stakeholder
 Präsentation des Product Increments
 Feedback der Stakeholder
 Aufnahme neuer Anforderungen
Seite 19
Dos & Don’ts – Sprint Review
 Sprint Review ist mehr als eine Demo! Nutze das Review, um das
Produkt zu begutachten und anzupassen
 Lade als PO die entscheidenden Stakeholder ein
 Präsentiere als PO überblicksartig, was umgesetzt wurde und was nicht
umgesetzt wurde
 Gib als PO einen Ausblick auf die nächsten Umsetzungen
 Entwickler zeigen die Umsetzungen an Stationen, wo die Stakeholder
mit der neuen Funktionalität “spielen” können
 Leite aus dem Feedback der Stakeholder neue Anforderungen ab
Seite 20
Sprint Retrospective
 Wer: Scrum Team – Scrum Master moderiert
 In Bezug auf Personen, Beziehungen, Prozesse & Werkzeuge:
 Was lief gut?
 Was könnte besser laufen?
Ende
Seite 21
Dos & Don’ts – Sprint Retrospective
 Leite aus dem “Was besser laufen könnte” Verbesserungsmaßnahmen
ab
 Setze im nächsten Sprint Verbesserungsmaßnahmen um und evaluiere
diese in der Retrospektive
 Keine Blame Games / keine Beschwerdesitzung – Retrospektiven sind
dazu da, Probleme zu lösen und die Teamarbeit zu verbessern
 Wenn das Team effizienter arbeitet, kann es auch besser Produkte
entwickeln
Kontakt
Dr. Sven Strobel – PO Scrum Team AV-Portal
T +49 511 762-14229, sven.strobel@tib.eu
MEHR INFORMATIONEN
av.tib.eu

Das TIB AV-Portal setzt auf das agile Management-Framework Scrum

  • 1.
    Dr. Sven Strobel(PO, Scrum Team AV-Portal) Leipzig, 20. März 2019 BibTag 2019 Das TIB AV-Portal setzt auf das agile Management- Framework Scrum Basics & Lessons Learned
  • 2.
    Agenda 1. Entwicklung desTIB AV-Portals 2. Was ist Scrum? 3. Rollen in Scrum 4. Ereignisse in Scrum
  • 3.
    Seite 3 Entwicklung desTIB AV-Portals // av.tib.eu Entwicklung  TIB und HPI / Yovisto  Online seit Frühjahr 2014 Management der Entwicklung  2011 - 2015: Wasserfallmodell  2015 - 2017: Integration agiler Methoden  2018: Umstellung auf Scrum Profil  Freies Portal für wissenschaftliche AV-Medien aus Technik & Natur- wissenschaften
  • 4.
    Agenda 1. Entwicklung desTIB AV-Portals 2. Was ist Scrum? 3. Rollen in Scrum 4. Ereignisse in Scrum
  • 5.
    Seite 5 Was istScrum?  Scrum ist ein Management-Rahmenwerk zur Entwicklung komplexer Produkte  Scrum besteht aus definierten Rollen, Ereignissen, Artefakten sowie den Regeln, die sie miteinander verbinden  Produkt, Prozesse & Methoden werden in Scrum regelmäßig überprüft und angepasst (empirische Prozesssteuerung) (*) (*) Schwaber, Ken & Sutherland, Jeff (2013). The Scrum GuideTM, the Definitive Guide to Scrum: The Rules of the Game, scrum.org.
  • 6.
    Seite 6 Sprint-Zyklus inScrum Sprint 4 Wochen Daily Scrum Priorität Product Backlog Sprint Backlog Product Increment
  • 7.
    Agenda 1. Entwicklung desTIB AV-Portals 2. Was ist Scrum? 3. Rollen in Scrum 4. Ereignisse in Scrum
  • 8.
    Seite 8 Rollen inScrum Product Owner  Priorisierung der Anforderungen  Abnahme des Product Increment Entwickler  Umsetzung der Anforderungen Scrum Master  Verantwortlich für Einhaltung der Scrum- Regeln  Beseitigung von Hindernissen Entwicklerteam Scrum Team
  • 9.
    Agenda 1. Entwicklung desTIB AV-Portals 2. Was ist Scrum? 3. Rollen in Scrum 4. Ereignisse in Scrum
  • 10.
    Seite 10 Ereignisse inScrum  Der Sprint ist der Container für alle übrigen Ereignisse in Scrum:  Sprint Planning  Daily Scrum  (Backlog Grooming)  Sprint Review  Sprint Retrospective Überprüfung & Anpassung von Produkt, Prozessen und Methoden
  • 11.
    Seite 11 Sprint  Containerfür alle (übrigen) Ereignisse in Scrum  Feste Timebox: 2 - 4 Wochen  Ziel: Herstellung eines auslieferbaren Produktinkrements
  • 12.
    Seite 12 Sprint Planning Wer: Product Owner & Entwickler  Was sind die umzusetzenden Anforderungen?  Wie sind sie priorisiert?  Wie werden diese Anforderungen realisiert?  Tasks  Ergebnis: Sprint Backlog Start
  • 13.
    Seite 13 Dos &Don’ts – Sprint Planning  Plane maximal 2 Stunden pro Woche des Sprints für das Sprint Planning ein  Bereite das Product Backlog (Priorität, Detaillierung & Schätzung) gut vor  Sprint Planning effektiver  Berücksichte die durchschnittliche Velocity des Teams (z.B. der letzten 3 Sprints) sowie Urlaube, Dienstreisen & Feiertage  Plane nicht den perfekten Plan. Konkretisiere die Dinge im Laufe des Sprints: Welche Aufgabe kommt zuerst?, Wer macht das?, Wie lange dauert das?...  Breche zu große Backlog-Einträge auf mehrere kleine Einträge herunter (z.B. per Obergrenze: 13 Pts.)
  • 14.
    Seite 14 Daily Scrum Wer: Entwickler, (Product Owner)  Timebox: 15 min  Zweck: Tägliche Überprüfung, Sychronisierung & adaptive Planung  Was habe ich gestern getan?  Was werde ich heute tun?  Gibt es Hindernisse?
  • 15.
    Seite 15 Dos &Don’ts – Daily Scrum  Führe das Daily Scrum täglich durch (am besten vormittags)  Halte die Timebox von 15 min ein  Alle erscheinen pünktlich  Entwickler führen das Daily Scrum selbst durch – ohne Lead  Nimm als PO an den Dailies teil  Nutze ein Board für die aktuellen Tasks und aktualisiere es im Daily Scrum  Bespreche aufkommene Probleme in einem Anschlusstreffen mit den dafür relevanten Beteiligten
  • 16.
    Seite 16 Backlog Grooming Kein offizielles Scrum-Ereignis  Wer: Product Owner & Entwickler  Input: Product Backlog  Detaillieren, Priorisieren & Schätzen der Backlog-Einträge  Vorbereitung der nächsten Sprints  Entfernen von Backlog-Einträgen, die nicht mehr relevant sind
  • 17.
    Seite 17 Dos &Don’ts – Backlog Grooming  Führe pro Sprint mind. 1 Backlog Grooming durch  Überprüfe das Product Backlog und organisiere es kontinuierlich neu  Ziel: das Team erledigt die wichtigsten Arbeiten für das Produkt  Detailliere und schätze hochpriorisierte Backlog-Einträge; niedrig- priorisierte Einträge können vage bleiben  Bereite die nächsten beiden Sprints vor  Gruppiere zusammengehörige Backlog-Einträge in Epics
  • 18.
    Seite 18 Sprint Review Wer: Scrum Team & Stakeholder  Präsentation des Product Increments  Feedback der Stakeholder  Aufnahme neuer Anforderungen
  • 19.
    Seite 19 Dos &Don’ts – Sprint Review  Sprint Review ist mehr als eine Demo! Nutze das Review, um das Produkt zu begutachten und anzupassen  Lade als PO die entscheidenden Stakeholder ein  Präsentiere als PO überblicksartig, was umgesetzt wurde und was nicht umgesetzt wurde  Gib als PO einen Ausblick auf die nächsten Umsetzungen  Entwickler zeigen die Umsetzungen an Stationen, wo die Stakeholder mit der neuen Funktionalität “spielen” können  Leite aus dem Feedback der Stakeholder neue Anforderungen ab
  • 20.
    Seite 20 Sprint Retrospective Wer: Scrum Team – Scrum Master moderiert  In Bezug auf Personen, Beziehungen, Prozesse & Werkzeuge:  Was lief gut?  Was könnte besser laufen? Ende
  • 21.
    Seite 21 Dos &Don’ts – Sprint Retrospective  Leite aus dem “Was besser laufen könnte” Verbesserungsmaßnahmen ab  Setze im nächsten Sprint Verbesserungsmaßnahmen um und evaluiere diese in der Retrospektive  Keine Blame Games / keine Beschwerdesitzung – Retrospektiven sind dazu da, Probleme zu lösen und die Teamarbeit zu verbessern  Wenn das Team effizienter arbeitet, kann es auch besser Produkte entwickeln
  • 22.
    Kontakt Dr. Sven Strobel– PO Scrum Team AV-Portal T +49 511 762-14229, sven.strobel@tib.eu MEHR INFORMATIONEN av.tib.eu