Video Nr. 3 aus dem agilecoach.de Ausbildungskanal auf YouTube: “Das Scrum Framework”.
Im Vergleich zum letzten Video habe ich mir fast 10 mal mehr Zeit genommen, um Scrum zu erklären. Aus 90 Sekunden sind eine knappe Viertelstunde geworden.
<< Hier geht’s zum Ausbildungskanal auf YouTube >>
Hier direkt das Video…
Vollständige Transkiption des Videos bzw. an dieser Stelle das Script, auf dessen Basis dieses Video entstand:
Das Scrum Framework
Scrum ist ein Framework, um innovative Produktentwicklungsprojekte agil durchzuführen. Scrum kann aber auch genauso gut für die Durchführung beliebiger Projektvorhaben genutzt werden.
Jedes Projekt hat eine grundsätzliche Produkt-Idee oder eine Produkt-Vision, die erreicht oder umgesetzt werden soll.
Aus dieser Idee und der Vision ergeben sich jede Menge Anforderungen und konkrete Wünsche für die Umsetzung.
In Scrum schreiben wir diese ersten, groben Ideen in das sogenannte Product Backlog. Das Product Backlog ist eine priorisierte Liste von Anforderungen, Themen und Ideen für das Produkt. Oben befinden sich die wichtigsten, unten die unwichtigsten Anforderungen. Die Einträge im Product Backlog sind um so detaillierter und kleiner, je weiter oben sie sich befinden.
Im oberen Drittel finden sich kleine Anforderungen, die direkt in die Umsetzung gehen können. Im mittleren Drittel befinden sich größere Themen, die noch genauer detailliert und runtergebrochen werden müssen. Das untere Drittel enthält ganz grobe Ideen, die zukünftig vielleicht mal kommen könnten und zu denen wir aktuell noch gar keine Details kennen.Es gibt in Scrum die Rolle des Product Owners. Der Product Owner ist eine Person, die für das Product Backlog verantwortlich ist und über den gesamten Inhalt des Backlogs sowie dessen Priorisierung entscheiden kann.
Um die Anforderungen des Backlogs in ein funktionierendes Produkt zu verwandeln, benötigt der Product Owner ein schlagkräftiges Entwicklungsteam. Das Entwicklungsteam umfasst alle Disziplinen, die für die Entwicklung des Produktes benötigt werden. Je nach Branche und Umfeld des Teams bestehen die Teammitglieder aus Entwicklern, Testern, Usability-Experten und Designern, bis hin zu Leuten aus eigentlich entwicklungsfernen Bereichen wie zum Beispiel Marketing, Vertrieb oder Customer Care.
Die Umsetzung von Anforderungen in ein funktionierendes Produkt erfolgt in nacheinander sich wiederholenden Zyklen, den sogenannten Sprints. Ein Sprint dauert je nach Team zwischen 1 und 4 Wochen und umfasst alle nachfolgend beschriebenen Aktivitäten.Das Entwicklungsteam trifft sich mit dem Product Owner zum Sprint Planning Meeting. In diesem Treffen besprechen alle Beteiligten die obersten Einträge des Product Backlogs. Details und Akzeptanzkriterien werden geklärt, bis ein gemeinsames Verständnis und eine gemeinsame Erwartungshaltung bezüglich der Anforderungen entstanden ist. Das Entwicklungsteam bestimmt dann die Anzahl der Einträge aus dem Product Backlog, die während des kommenden Sprints vom Team umgesetzt werden können. Die Entscheidung über den Sprint-Umfang kann nur vom Entwicklungsteam getroffen werden. Die Anforderungen, die das Team aus dem Product Backlog in den Sprint hineinzieht, heißen Sprint Backlog. Im zweiten Schritt des Sprint Planning Meetings identifiziert das Entwicklungsteam die einzelnen, kleinen Aufgaben, die für die Umsetzung des Anforderungen des Sprint Backlogs erledigt werden müssen. Diese Aufgaben, auch Tasks genannt, werden mit dem Sprint Backlog auf einem sogenannten Task Board visualisiert.
Während des Sprints erfolgt nun die Abarbeitung der einzelnen Tasks. Das Entwicklungsteam koordiniert sich in einem kurzen, täglichen Treffen, dem sogenannten Daily Scrum Meeting. Dieses Treffen wird im Stehen vor dem Task Board abgehalten und dauert höchstens 15 Minuten. Ziel dieses Treffens ist, das gemeinsame Verständnis im Team herzustellen, was in den nächsten 24 Stunden wie getan werden muss, um das Sprintziel zu erreichen. Nach dem Daily Scrum wird der sogenannte Burndown Chart vom Team aktualisiert. In diesem Diagramm wird transparent gemacht, wie gut die Abarbeitung des Sprint Backlogs im aktuellen Sprint vonstatten geht.Ungefähr in der Mitte eines Sprints findet das Backlog Refinement Meeting statt, in dem sich der Product Owner mit dem Entwicklungsteam über die kommenden Anforderungen aus dem Product Backlog austauscht. Ziel des Backlog Refinements ist es, bereits vor dem nächsten Sprint Planning Meeting viele Details geklärt und ein gemeinsames Verständnis erarbeitet zu haben. Dadurch verkürzt sich der Aufwand für das Sprint Planning erheblich.
Am Ende des Sprints hat das Entwicklungsteam ein Ergebnis umgesetzt, welches das bislang entwickelte Produkt um weitere Funktionen und Features ergänzt. Wir sprechen vom sogenannten Produkt-Inkrement, welches in jedem Sprint erzeugt wird. Ziel der inkrementellen Produktentwicklung ist es, nach jedem Sprint ein funktionierendes, in sich abgeschlossenes Produkt zu erzeugen, welches für den Anwender einen Mehrwert darstellt.
Dieser Mehrwert muss jedoch festgestellt werden und wir müssen ebenso identifizieren, ob das bislang entwickelte Produkt noch den Anforderungen der Anwender entspricht, der maximale Kundennutzen bereits erzeugt wurde und ob das bestehende Product Backlog noch in die richtige Richtung zeigt. All diese Aspekte holen sich der Product Owner und das Entwicklungsteam über das Feedback aus dem Sprint Review Meeting. Im Sprint Review Meeting präsentiert das Entwicklungsteam die Ergebnisse aus dem letzten Sprint. Idealerweise nehmen am Sprint Review nicht nur der Product Owner, sondern vor Allem auch echte Anwender, Kunden und das Management teil, um das Produkt bewerten und neue Ideen für das Product Backlog entwickeln zu können. Dieses Feedback fließt durch den Product Owner in das Product Backlog und wird dort entsprechend priorisiert.Der Abschluss eines Sprints findet in Form des Sprint Retrospective Meetings statt. In dieser Retrospektive durchläuft das Scrum-Team einen kontinuierlichen Verbesserungsprozess. Das Team identifiziert die positiven und negativen Aspekte der eigenen Zusammenarbeit sowie der organisatorischen Gegebenheiten. Daraus werden dann konkrete Maßnahmen abgeleitet, welche im nächsten Sprint durchgeführt werden.
Nach der Retrospektive beginnt der Zyklus von Neuem und der nächste Sprint startet mit dem nächsten Sprint Planning Meeting. Es existiert keine Pause zwischen den Sprints, da die einzige Aufgabe des Scrum-Teams darin besteht, das Product Backlog in ein funktionierendes Produkt zu transformieren. Dieser Zyklus endet entweder, wenn der Product Owner im Sprint Review feststellt, dass das Produktziel erreicht ist und ein weiterer Sprint keinen Mehrwert mehr erzeugen würde. Oder er endet durch einen vorher fest definierten Termin, bis zu dem der maximale Mehrwert umgesetzt wurde.
In Scrum gibt es eine weitere, dritte Rolle, die wir bislang nicht erwähnt hatten: der Scrum Master. Der Scrum Master trägt die Verantwortung dafür, dass sich das Scrum-Team sicher und konsequent innerhalb des Scrum-Frameworks bewegt. Er sorgt dafür, dass das Team ungestört seiner Arbeit nachgehen kann, dass alle Scrum-Meetings durchgeführt werden und dass die Zusammenarbeit aller Beteiligten konstruktiv und effektiv stattfindet.
In den folgenden Videos werden wir auf die einzelnen Rollen, Meetings und Arbeitsmittel eines Scrum-Teams im Detail eingehen.
Im agilecoach.de Ausbildungskanal auf YouTube finden sich laufend neue Videos zu agilen Themen wie Scrum, Kanban, Lean, Lean Start-up und alle artverwandten Themen.
Ich freue mich über Eure Kommentare und vor allen Dingen über Eure Fragen, die ich in kommenden Videos beantworten kann. Schickt einfach eine Mail an marc.bless@agilecoach.de oder nutzt die Kommentarfunktion unter den Videos auf YouTube.