Einleitung und Motivation
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
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
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
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
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
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?
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.