Viele Scrum-Teams handhaben die Scrum-Events eher aus Gewohnheit oder sogar mechanisch. Diese Events sind oft unzureichend vorbereitet oder werden schlecht durchgeführt. Die Gründe dafür sind vielfältig, von Unerfahrenheit über mangelndes Wissen bis hin zu Unwillen. Oft ist auch unklar, was der tiefere Sinn hinter den Veranstaltungen ist, welchen Input sie brauchen und welchen konkreten Output sie liefern sollen. Dieser Artikel beschreibt die Inputs und Outputs der fünf Scrum-Events. Finden Sie heraus, was für jedes Event benötigt wird, was es liefern soll und welchen Wert es für Ihr Team hat.
Einleitung und Motivation
Wenn ich als Scrum Master in einem neuen Scrum-Team zu arbeiten beginne, fällt mir fast immer eines auf. Das Team weiß, welche Scrum Events es gibt, aber sie werden nicht entsprechend ihrer Bedeutung ausgeführt. In manchen Fällen werden einige der Events gar nicht ausgeführt, weil dem Team nicht klar ist, welchen Mehrwert das Event hat oder haben sollte.
Das mag sicherlich auch daran liegen, dass Scrum mittlerweile eines der am weitesten verbreiteten Frameworks in der Softwareentwicklung ist. Dass es drei Rollen, drei Säulen, drei Artefakte, fünf Werte und fünf Events gibt, ist denkbar einfach zu verstehen. Schwieriger wird es, die Metaebene von Scrum zu verstehen. Wofür sind diese Dinge da, wie greifen sie ineinander und ergänzen sich, und wie bekommt man sie in der Praxis zum Laufen? Wie der Scrum Guide 2017 sagt, ist Scrum „leicht zu verstehen“, aber „schwer zu meistern“.
Dieser Artikel soll einen Überblick über Scrum Events geben und insbesondere beleuchten, welche Inputs und Outputs mit ihnen verbunden sind. Welche Dinge muss ein Team als Input für seine Scrum Events berücksichtigen und welchen Mehrwert bzw. Output bringen diese Events für das Team. Ein Scrum-Team kann nur dann erfolgreich sein, wenn es versteht, dass es absolut notwendig ist, den Fokus darauf nicht zu verlieren.
Das mag sicherlich auch daran liegen, dass Scrum mittlerweile eines der am weitesten verbreiteten Frameworks in der Softwareentwicklung ist. Dass es drei Rollen, drei Säulen, drei Artefakte, fünf Werte und fünf Events gibt, ist denkbar einfach zu verstehen. Schwieriger wird es, die Metaebene von Scrum zu verstehen. Wofür sind diese Dinge da, wie greifen sie ineinander und ergänzen sich, und wie bekommt man sie in der Praxis zum Laufen? Wie der Scrum Guide 2017 sagt, ist Scrum „leicht zu verstehen“, aber „schwer zu meistern“.
Dieser Artikel soll einen Überblick über Scrum Events geben und insbesondere beleuchten, welche Inputs und Outputs mit ihnen verbunden sind. Welche Dinge muss ein Team als Input für seine Scrum Events berücksichtigen und welchen Mehrwert bzw. Output bringen diese Events für das Team. Ein Scrum-Team kann nur dann erfolgreich sein, wenn es versteht, dass es absolut notwendig ist, den Fokus darauf nicht zu verlieren.
Der Sprint
Mit der Veröffentlichung des Scrum Guide 2020 wurde der Sprint selbst zum fünften Scrum-Event ernannt. Der Sprint ist ein Container für alle Aktivitäten und Arbeiten, die notwendig sind, um das Produktziel zu erreichen. Dazu gehören die vier anderen Scrum-Events, das Refinement, die eigentlichen Entwicklungstätigkeiten oder z.B. die Abstimmung mit Stakeholdern.
Inputs für einen Sprint sind immer das Product Backlog, eine Vision des Product Owners bezüglich eines möglichen Sprint Goals, die verfügbaren Fähigkeiten und Kapazitäten des Teams für den Sprint und das Produktinkrement, das als Ergebnis des letzten Sprints erstellt wurde.
Outputs eines Sprints sind das neu erstellte Produktinkrement sowie eine weitere Iteration des Product Backlogs. Dieses wurde vom Team während des Sprints verfeinert und erweitert oder anderweitig angepasst. Es stellt also die aktuelle Sicht des Teams auf die Anforderungen an das Produkt dar.
Inputs für einen Sprint sind immer das Product Backlog, eine Vision des Product Owners bezüglich eines möglichen Sprint Goals, die verfügbaren Fähigkeiten und Kapazitäten des Teams für den Sprint und das Produktinkrement, das als Ergebnis des letzten Sprints erstellt wurde.
Outputs eines Sprints sind das neu erstellte Produktinkrement sowie eine weitere Iteration des Product Backlogs. Dieses wurde vom Team während des Sprints verfeinert und erweitert oder anderweitig angepasst. Es stellt also die aktuelle Sicht des Teams auf die Anforderungen an das Produkt dar.
Sprint Planning
Im Scrum Guide 2020 heißt es: „Das Sprint Planning leitet den Sprint ein, indem es die Arbeit festlegt, die für den Sprint durchgeführt werden soll. Dieser resultierende Plan wird durch die gemeinschaftliche Arbeit des gesamten Scrum-Teams erstellt.“ Daher soll das Team die folgenden drei Fragen beantworten. „Warum ist dieser Sprint wertvoll?“, „Was kann in diesem Sprint getan (done) werden?“ und „Wie wird die ausgewählte Arbeit erledigt?“ In anderen, einfacheren Worten: Das Scrum-Team soll einen Plan für den nächsten Sprint erstellen. Dazu muss es ein Ziel definieren, das erreicht werden soll, die Aktivitäten, die dazu durchgeführt werden müssen, und einen Plan, wie diese Aktivitäten durchgeführt werden sollen.
Inputs für das Sprint Planning sind also das Product Backlog, wie es steht, die Fähigkeiten und Kapazitäten des Teams im nächsten Sprint und die Vision des Product Owners für ein sinnvolles und wertvolles Sprint Goal. Das Product Backlog ist die Quelle der Anforderungen, aus denen das Sprint Backlog ausgewählt werden kann. Die Idee oder Vision des Product Owners für den Sprint ist die Leitlinie für die Auswahl dieser Aufgaben. Die Kapazitäten und Fähigkeiten dienen als Einschränkungen für die Menge der Arbeit, die ausgewählt werden kann, sowie für die Art der Arbeit, die ausgewählt werden kann. So sollte z.B. eine Datenbankimplementierung nur dann geplant werden, wenn im nächsten Sprint Entwickler mit entsprechender Expertise zur Verfügung stehen.
Outputs des Sprint Planning sind das Sprint-Ziel, das Sprint-Backlog und der Plan, wie diese Arbeit durchgeführt und abgeliefert werden soll. Einfacher ausgedrückt, sind die Outputs das Ziel, das erreicht werden soll, die ToDo-Liste der Dinge, die dafür getan werden müssen, und eine Vorstellung davon, „wer was macht und in welcher Reihenfolge wir es tun“.
Inputs für das Sprint Planning sind also das Product Backlog, wie es steht, die Fähigkeiten und Kapazitäten des Teams im nächsten Sprint und die Vision des Product Owners für ein sinnvolles und wertvolles Sprint Goal. Das Product Backlog ist die Quelle der Anforderungen, aus denen das Sprint Backlog ausgewählt werden kann. Die Idee oder Vision des Product Owners für den Sprint ist die Leitlinie für die Auswahl dieser Aufgaben. Die Kapazitäten und Fähigkeiten dienen als Einschränkungen für die Menge der Arbeit, die ausgewählt werden kann, sowie für die Art der Arbeit, die ausgewählt werden kann. So sollte z.B. eine Datenbankimplementierung nur dann geplant werden, wenn im nächsten Sprint Entwickler mit entsprechender Expertise zur Verfügung stehen.
Outputs des Sprint Planning sind das Sprint-Ziel, das Sprint-Backlog und der Plan, wie diese Arbeit durchgeführt und abgeliefert werden soll. Einfacher ausgedrückt, sind die Outputs das Ziel, das erreicht werden soll, die ToDo-Liste der Dinge, die dafür getan werden müssen, und eine Vorstellung davon, „wer was macht und in welcher Reihenfolge wir es tun“.
Daily Scrum
Das Daily Scrum ist das tägliche Scrum-Event der Entwickler im Scrum Team. Das Ziel des Daily Scrum ist es, das Sprint Backlog zu inspizieren und den Fortschritt gegenüber dem Sprint Goal zu überprüfen. Gegebenenfalls muss dann angepasst werden, welche nächsten Schritte das Team unternehmen wird, um dieses Ziel zu erreichen.
Inputs des Daily Scrum sind also der aktuelle Stand des Sprint Backlogs und des Sprint Goals. Das Sprint Backlog muss nicht nur täglich aktualisiert werden, sondern auch den Status Quo zu Beginn des Daily Scrums widerspiegeln. Darüber hinaus ist die Kenntnis des aktuellen Plans des Teams, wie das Sprint Goal erreicht werden soll, als Input notwendig. Nur wenn der Status Quo, das zu erreichende Ziel und der Weg dorthin dem Team klar sind, kann der Weg entsprechend angepasst werden.
Output des Daily Scrum ist ein Plan für die nächsten 24 Stunden, den nächsten Arbeitstag. Dem Team ist klar, in welcher Form es vorgehen wird, um das Sprint-Ziel zu erreichen. Dazu gehören die Beseitigung von Hindernissen, die Zusammenarbeit der Entwickler mit Techniken wie Pair Programming und die Verteilung der verschiedenen Aufgaben im Team.
Inputs des Daily Scrum sind also der aktuelle Stand des Sprint Backlogs und des Sprint Goals. Das Sprint Backlog muss nicht nur täglich aktualisiert werden, sondern auch den Status Quo zu Beginn des Daily Scrums widerspiegeln. Darüber hinaus ist die Kenntnis des aktuellen Plans des Teams, wie das Sprint Goal erreicht werden soll, als Input notwendig. Nur wenn der Status Quo, das zu erreichende Ziel und der Weg dorthin dem Team klar sind, kann der Weg entsprechend angepasst werden.
Output des Daily Scrum ist ein Plan für die nächsten 24 Stunden, den nächsten Arbeitstag. Dem Team ist klar, in welcher Form es vorgehen wird, um das Sprint-Ziel zu erreichen. Dazu gehören die Beseitigung von Hindernissen, die Zusammenarbeit der Entwickler mit Techniken wie Pair Programming und die Verteilung der verschiedenen Aufgaben im Team.
Sprint Review
„Der Zweck des Sprint-Reviews ist es, das Ergebnis des Sprints zu überprüfen und zukünftige Anpassungen festzulegen. Das Scrum Team präsentiert den wichtigsten Stakeholdern die Ergebnisse seiner Arbeit und der Fortschritt in Richtung des Produktziels wird diskutiert.“ Während des Sprint Reviews inspiziert das Team, was tatsächlich getan wurde, und noch wichtiger, was nicht getan wurde. Dies kann zu wertvollem Input für die Sprint Retrospektive führen. Die Arbeit, die nicht erledigt wurde, wird zurück ins Product Backlog verschoben. Das Feedback der Stakeholder kann zu neuen Prioritäten führen, und so kann sich die Reihenfolge des Product Backlogs ändern. Außerdem prüft das Team, ob es noch auf dem „richtigen Weg“ ist und ob es wertvolle Arbeit im Hinblick auf das Produktziel abliefert.
Inputs für das Sprint Review sind daher das Sprint Backlog und das Sprint Goal, sowie das Product Increment und das Product Goal.
Outputs des Sprint Reviews sind eine überarbeitete Version des Product Backlogs, wertvolles Stakeholder-Feedback und Beobachtungen, die in der Sprint-Retrospektive diskutiert werden können.
Inputs für das Sprint Review sind daher das Sprint Backlog und das Sprint Goal, sowie das Product Increment und das Product Goal.
Outputs des Sprint Reviews sind eine überarbeitete Version des Product Backlogs, wertvolles Stakeholder-Feedback und Beobachtungen, die in der Sprint-Retrospektive diskutiert werden können.
Sprint Retrospektive
Die Sprint Retrospektive schließt den Sprint ab und ist die Gelegenheit für das Scrum Team, sich selbst, seine Prozesse, seine Entwicklungstechniken und alles andere, was das Team betrifft, zu überprüfen. Das Ziel ist es, Wege zu finden, die Effektivität und Effizienz zu steigern.
Inputs für die Sprint Retrospektive sind positive und negative Aspekte des letzten Sprints. Obwohl bei negativen Aspekten wahrscheinlich Verbesserungen vorgenommen werden, ist es wichtig, die guten Dinge, die in den letzten Wochen passiert sind, nicht zu vergessen. Zusätzlich kann das Sprint Review Input für die Sprint Retrospektive geliefert haben, wenn der Sprint nicht erfolgreich war oder Stakeholder-Feedback bezüglich der Qualität der Produktinkremente diskutiert wurde.
Outputs der Sprint Retrospektive sind Aktionspunkte, die dann im Product Backlog festgehalten werden. Laut dem Scrum Guide 2017 sollte mindestens eine dieser Prozessverbesserungen im kommenden Sprint geplant werden. Der Scrum Guide 2020 sagt uns, dass wir diese Punkte so schnell wie möglich abarbeiten sollen, auch wenn es nicht direkt im nächsten Sprint sein muss.
Inputs für die Sprint Retrospektive sind positive und negative Aspekte des letzten Sprints. Obwohl bei negativen Aspekten wahrscheinlich Verbesserungen vorgenommen werden, ist es wichtig, die guten Dinge, die in den letzten Wochen passiert sind, nicht zu vergessen. Zusätzlich kann das Sprint Review Input für die Sprint Retrospektive geliefert haben, wenn der Sprint nicht erfolgreich war oder Stakeholder-Feedback bezüglich der Qualität der Produktinkremente diskutiert wurde.
Outputs der Sprint Retrospektive sind Aktionspunkte, die dann im Product Backlog festgehalten werden. Laut dem Scrum Guide 2017 sollte mindestens eine dieser Prozessverbesserungen im kommenden Sprint geplant werden. Der Scrum Guide 2020 sagt uns, dass wir diese Punkte so schnell wie möglich abarbeiten sollen, auch wenn es nicht direkt im nächsten Sprint sein muss.
Was ist mit Refinement?
Nun, technisch gesehen ist das Refinement kein Scrum Event. Allerdings halten viele Teams ihre Refinements als Meetings ab, und jedes Meeting soll einen Input oder eine Agenda haben, und natürlich soll es einen Wert für das Unternehmen liefern. Es soll also einen Output produzieren. Wird im Scrum Guide beschrieben als „der Akt des Herunterbrechens und der weiteren Definition von Product Backlog-Elementen in kleinere, präzisere Elemente. Dies ist eine fortlaufende Aktivität, um Details hinzuzufügen, wie z. B. eine Beschreibung, Reihenfolge und Größe. Die Attribute variieren oft mit der Domäne der Arbeit.“
Bei der Verfeinerung wird das Product Backlog mit zusätzlichen Informationen angereichert. Dies kann durch das Hinzufügen von Informationen zu bereits bestehenden Anforderungen, das Gewinnen von Klarheit durch Diskussionen, das Aufteilen von Anforderungen oder das Schreiben neuer Anforderungen in das Backlog geschehen. Auf diese Weise entwickelt sich das Product Backlog bei jedem Refinement weiter und die Anforderungen werden für die Planung in einem der nächsten Sprints vorbereitet. Input und Output der Verfeinerungsaktivitäten sind also verschiedene Versionen/Iterationen des Product Backlogs.
Bei der Verfeinerung wird das Product Backlog mit zusätzlichen Informationen angereichert. Dies kann durch das Hinzufügen von Informationen zu bereits bestehenden Anforderungen, das Gewinnen von Klarheit durch Diskussionen, das Aufteilen von Anforderungen oder das Schreiben neuer Anforderungen in das Backlog geschehen. Auf diese Weise entwickelt sich das Product Backlog bei jedem Refinement weiter und die Anforderungen werden für die Planung in einem der nächsten Sprints vorbereitet. Input und Output der Verfeinerungsaktivitäten sind also verschiedene Versionen/Iterationen des Product Backlogs.
Abschließende Gedanken
Hoffentlich ist Ihr Team bereits mit den Inputs und Outputs von Scrum Events vertraut. Wenn Sie in diesem Artikel keine neuen Informationen gefunden haben, dann herzlichen Glückwunsch, Ihr Scrum-Wissen ist nicht so schlecht. Wenn Ihr Team diese Inputs und Outputs auch aktiv im Auge behält, umso besser. Sie sind auf dem besten Weg, ein erfolgreiches Scrum-Team zu werden. Wenn Sie neue Informationen in diesem Artikel gefunden haben, freue ich mich, dass Sie etwas gelernt haben. Stellen Sie nur sicher, dass Sie sich an diese Inputs und Outputs von Scrum Events erinnern, wenn Sie das nächste Mal an einer teilnehmen. Erinnern Sie sich und Ihr Team immer wieder daran, wozu diese Veranstaltungen dienen und dass Sie nur erfolgreich sein können, wenn Sie sich dessen bewusst sind und den Fokus nicht verlieren.
