SCRUM in der Anwendung - Sprint Planung

623 Aufrufe

Veröffentlicht am

Basierend auf ihren Best Practice Erfahrungen beschreibt Senior Consultant Jin-Young Lee, wie man als Scrum-Team zusammenarbeiten sollte, damit ein Sprint optimal vorbereitet und durchgeführt werden kann.

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

  • Gehören Sie zu den Ersten, denen das gefällt!

Keine Downloads
Aufrufe
Aufrufe insgesamt
623
Auf SlideShare
0
Aus Einbettungen
0
Anzahl an Einbettungen
15
Aktionen
Geteilt
0
Downloads
4
Kommentare
0
Gefällt mir
0
Einbettungen 0
Keine Einbettungen

Keine Notizen für die Folie

SCRUM in der Anwendung - Sprint Planung

  1. 1. Wie sieht eine „ideale“ Sprintplanung aus? JIN-YOUNG LEE SCRUM in der Anwendung – Sprint Planung – OKTOBER 2015
  2. 2. 2 Scrum in der Anwendung – Product Backlog Ziele und Inhalte des Tutorials » Mit Hilfe dieses Tutorials soll Product Ownern / Scrum Teams vorgestellt werden, wie man einen „idealen“ Sprintablauf planen kann. » Das Tutorial beschäftigt sich mit den folgenden Punkten: 1. Wie plant man einen Sprint? 2. Wie plane man ein Release? » Die Erkenntnisse aus diesem Tutorial sind Best Practice Methoden, die im Rahmen der Kundenprojekten gewonnen und eingesetzt wurden.
  3. 3. Scrum in der Anwendung – Sprint Planung 3 Sprintplanung
  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 (Grooming, Sprint Planning, Daily Stand-Up, 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. 2. Der „ideale“ Sprint-Ablauf Sprint n-1 Sprint n Sprint n+1 Product Owner  Aus Requirements Epics ableiten (fachlich)  Abnahme des Epics durch Stakeholder Architekt  Aus Requirements Epics ableiten (technisch) Entwickler  Kein ToDo Tester  Kein ToDo Product Owner / Architekt  User Stories inkl. Akzeptanzkriterien erstellen  Vorstellung der Stories für Grooming/Estimation  Klärung von Fragen Team  Estimation der User Stories im Product Backlog  Anbringen von Fragen Tester  Erstellung der Testszenarien für geschätzte User Stories (fachlich) Product Owner  Abnahme der erledigten User Stories im Sprint-Review Team  Ableiten der Subtasks pro User Story Entwickler  Umsetzung der User Stories  Code Review Tester  Testfallerstellung und Testdurchführung (nur, wenn Test Teil der Definition of Done einer User Story ist) * Sofern unterschiedliche Rollen (z.B. Architekt, Entwickler, Tester) im Scrum-Team vorhanden sind, sollten die Aufgaben auch unterschieden werden. 5
  6. 6. 3. Positive Effekte eines „idealen“ Sprint-Ablaufs » Wenn das Team im Laufe der Zeit eingespielt ist und der Sprint (nahezu) ideal abläuft, hat das folgende Einflüsse auf die Effektivität des Teams: » Im Product Backlog gibt es geschätzte User Stories, die sich die Entwickler nehmen können, sobald sich im laufenden Sprint „nichts mehr zu tun“ haben. » Der Product Owner kann anhand der Velocity genau einschätzen, wie viele User Stories bzw. Story Points das Team in den folgenden Sprints umsetzen kann. Er hat somit eine Planungssicherheit und kann auch zum Management hin, besser argumentieren. » Das Sprint Planning 1 kann innerhalb kürzester Zeit abgehandelt warden, da bereits alle User Stories besprochen und geschätzt vorliegen. Der Product Owner muss nur noch die Priorisierung festlegen und das Team sich dazu committen. Anschließend kann das Team unmittelbar mit dem Erstellen der Tasks (Sprint Planning 2) beginnen. 6
  7. 7. Scrum in der Anwendung – Sprint Planung 7 Releaseplanung
  8. 8. Releaseplanung vs. Sprintplanung » Nach der reinen Scrum-Lehre soll am Ende jedes Sprints ein „potentiell auslieferbares Artefakt“ erstellt werden. » Im Normalfall ist das jedoch nicht der Fall. Es gibt weiterhin eine übergreifende Releaseplanung. » D.h. über eine Zeitdauer von mehreren Sprints werden die für das nächste Release benötigten Features (in Form von User Stories) umgesetzt. » Anschließend wird ein Release (also ein „auslieferbares Artefakt“) gebaut und ausgeliefert. 8
  9. 9. Releaseplanung vs. Sprintplanung Entwicklung R1 Entwicklung R1 Entwicklung R1 Release 1 * Test R1 Go Live R1 Entwicklung R2 Entwicklung R2 … Planung R2 Release Sprint Entwicklungs- Stop R1 …  * Release beinhaltet u.a. das Bauen eines Release, das Deployment, ein Smoke Test sowie die Bereitstellung aller benötigen Dokumentationen 9
  10. 10. Scrum in der Anwendung – Sprint Planung 10 Zusammenfassung
  11. 11. Scrum in der Anwendung – Product Backlog Zusammenfassung » Jedes Team steht einmal am Anfang. Bis es den für das jeweilige Scrum-Team idealen Sprintablauf findet, kann einige Zeit vergehen (Forming, Storming, Norming, Performing) » Es gibt auch Teams, wo es nie zu einem regelmäßigen Sprint- Ablauf kommt und diese nur von Sprint zu Sprint arbeiten. Dies ist jedoch kein wünschenswerter Zustand und sollte von allen Teammitgliedern (insbesondere vom Product Owner) verhindert werden. » In beiden Fällen dient das Retrospektive-Meeting als Chance, die Zusammenarbeit besser und effektiver zu gestalten. Während der Meetings wird die Zusammenarbeit kritisch betrachtet und Maßnahmen dazu abgeleitet. 11
  12. 12. 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!

×