Du hast in Teil I schon die Werte und die verschiedenen Rollen im Scrum Prozess kennengelernt. Hierzu gehören auch verschiedene Meeting Formate. Jetzt kommen wir dazu, was das für Meetings sind und warum dein Team diese braucht.
Feste Meetings sind ein wichtiger Bestandteil des Scrum Prozesses
Der Scrum Prozess besteht auf wiederkehrenden Sprints. Sprints sind fest definierte Zeitintervalle, in denen das Scrum-Team an der Erreichung der vereinbarten Aufgaben arbeitet. Ein Sprint kann zwischen einer und vier Wochen dauern. Durch die kurzen Abstände zwischen den Meetings zur Abstimmung kann das Team schnell auf entstehende Veränderungen reagieren und erfährt nicht erst bei Abgabe des Produktes, dass die Vorgaben schon nicht mehr aktuell sind. Man kann also sagen, dass die Qualität der Planung hierdurch deutlich ansteigt. Zwischen den einzelnen Sprints gibt es keine Pausen, sie gehen nahtlos ineinander über. Dabei haben auch alle Sprints dieselbe Länge. Das gilt so lange, bis das Team feststellt, dass das Zeitintervall zu groß oder zu gering ist und eine Änderung beschließt. Nach jedem Sprint entscheidet euer Stakeholder oder euer Product Owner in Abstimmung mit den Stakeholdern darüber, ob ein weiterer Sprint notwendig ist oder nicht. Wenn das ausgelieferte Produkt den Anforderungen der Kund:innen entspricht und diese zufrieden sind, kann die Arbeit am Projekt beendet und ein neues angegangen werden. Wenn es noch Optimierungsbedarf geben sollte, erfolgt ein weiterer Sprint.
Meetings strukturieren einen Sprints
Ok, jetzt weißt du also, dass der Scrum Prozess durch Sprints strukturiert wird. Diese Sprints bekommen ihre Struktur wiederum durch eine feste Abfolge von Scrum Meetings. Ich weiß, dass das jetzt erstmal nach ziemlich viel Meetingkultur klingt. Aber wenn ihr diese Meetings effektiv durchführt, werden sie euch mehr Zeit einsparen, als ihr dafür aufwenden müsst. Jetzt möchte ich dir die verschiedenen Meetings innerhalb eines Sprints vorstellen.
Das Daily Stand Up
Wie der Name „Daily“ schon sagt, ist dies ein Meeting, das jeden Tag stattfindet. Die festgelegte Timebox hierfür sind maximal 15 Minuten. Während des Dailys stimmt sich das Entwicklungsteam untereinander darüber ab, was es an wichtigen Updates gibt. Was konnte in den letzten 24 Stunden erreicht werden? Was wird bis zum nächsten Daily Stand Up erreicht? Wo gibt es Probleme? An welchem Punkt benötigt jemand Unterstützung? Da dieses Meeting maximal eine Viertelstunde dauert, findet es bei vielen Teams im Stehen ab, weshalb es auch „Stand Up“ heißt. Nach dieser kurzen Abstimmung kann das Team mit der täglichen Arbeit beginnen.
Das Sprint Planning
Der Sprint startet immer mit dem Sprint Planning. Klingt schon logisch, oder? Das gesamte Scrum-Team nimmt daran teil. Hierzu wird das vom Product Owner priorisierte Backlog zur Hand genommen und die anstehenden Aufgaben mit dem zugehörigen erwarteten Arbeitsaufwand diskutiert. Nach der Einschätzung des Aufwandes legt das Team fest, welche Aufgaben es innerhalb des kommenden Sprints erledigen kann. Die Entscheidung darüber, wie viele Aufgaben ein Team bewältigen kann, hängt allein vom geschätzten Aufwand ab. Der Product Owner hat nicht die Macht, zusätzliche Aufgaben zu verteilen. Er hat seine Arbeit mit der Priorisierung des Backlogs und dessen Erläuterung an das Entwickler:innen-Team getan. Er steht selbstverständlich für Fragen und Anmerkungen zur Seite, steht allerdings nicht über der Einschätzung seiner Expert:innen. Ein Sprint Planning hat eine maximale Dauer von 8 Stunden für einen Sprint von 4 Wochen. Wenn du und dein Team ein kürzeres Intervall auswählt, kannst du die Zeit für das Planning entsprechend herunterrechnen.
Das Sprint Review
Am Ende jedes Sprints erfolgt die Demonstration der Arbeitsergebnisse im Sprint Review. Dieses Meeting hat eine maximale Timebox von 4 Stunden. Am Review nehmen das Entwickler:innen-Team, der Product Owner und bei Wunsch auch interessierte Stakeholder teil. Nachdem das Team die erbrachte Leistung und das Teilprodukt präsentiert hat, haben die anderen Teilnehmenden die Möglichkeit, Fragen zu stellen und ihr Feedback abzugeben. Damit können sie auf die zukünftige Arbeit und die mögliche Priorisierung von bestimmten Teilaufgaben Einfluss nehmen. Der Product Owner nimmt diese Anmerkungen auf und trifft eine Entscheidung über die Priorisierung.
Die Retrospektive
Kommen wir zum persönlichsten Teil eines Scrum Prozesses – der Retrospektive. Diese findet im Anschluss zum Review statt, ohne das Beisein der Stakeholder und Kund:innen. Es ist ein rein teaminternes Meeting, an dem das komplette Scrum-Team teilnimmt. Eine besondere Rolle kommt in diesem Meeting, das maximal 3 Stunden dauert, dem Scrum Master zu. Er moderiert den Termin, in dem die Zusammenarbeit innerhalb des letzten Sprints reflektiert und ggf. Änderungen für die künftigen Sprints vereinbart werden. Im ersten Schritt werden Informationen und Eindrücke gesammelt („Was ist passiert?“). Anschließend wird bewertet, was gut und was schlecht gelaufen ist. Anhand dieser Daten trifft das Team gemeinsam die Entscheidung, ob es neue Methoden oder Regeln ausprobieren möchte. Diese werden dann als To Dos für die zukünftigen Sprints festgehalten. Der Scrum Master hält nach, ob die vereinbarten Veränderungen vom Team auch eingehalten werden. Diese Dinge auszusprechen und festzuhalten, mag sich am Bildschirm jetzt erstmal einfach lesen. Ich kann dir aus meiner eigenen Erfahrung sagen, dass das in der Praxis nicht so ist. Wir sind alle Menschen und wollen gut miteinander klarkommen. Um Prozesse zu verbessern, ist es aber absolut notwendig, Dinge, die nicht so gut funktionieren, anzusprechen. Dazu benötigt jedes Teammitglied Offenheit, ein hohes Maß an Selbstreflexion und den Wunsch nach ständiger Verbesserung des Teams. In der Retrospektive kommen die agilen Prinzipien und Werte also am deutlichsten zum Tragen. Lass dich aber nicht entmutigen, wenn die ersten Retros nur schleppend laufen. Dein Team muss sich erst an die neue Form der Zusammenarbeit gewöhnen. Außerdem ist es menschlich, sich Kritik erstmal zu Herzen zu nehmen. Bis sich dies ändert und jede Person das Kritik zum Wohl des Teams auf einer sachlichen Basis äußern und auch annehmen kann, dauert es einige Zeit.
Das Product Backlog Refinement
Inhalt und Zusammenarbeit sind geklärt, was kann es denn jetzt noch abzustimmen geben fragst du dich vermutlich? Vor dem Sprint Planning ist es sinnvoll, wenn sich Product Owner und Entwicklungsteam einmal zusammensetzen und sich über den Umfang der Aufgaben im Product Backlog und die entsprechenden Erfüllungskriterien abstimmen. Eine Aufgabe kann z. B. „Website Relaunch“ heißen. Wie du aber schon gelernt hast, geht es in einem Sprint darum, ein definiertes Teilstück auszuliefern, das Kund:innen bewerten können. Aus der großen Aufgabe „Website Relaunch“ resultieren also viele verschiedene Unteraufgaben. Dies können z. B. Neue Bilder, die Einrichtung eines Newsletters, neue Texte oder die Integration eines neuen Portals sein. Je genauer und kleiner du die Aufgaben definierst, desto besser wirst du den damit einhergehenden Aufwand einschätzen können. Die kompletten Bilder für die Website innerhalb von maximal vier Wochen zu schießen oder alle Texte neu zu schreiben, ist sicher mehr als sportlich. Brich diese Aufgaben also in weitere Teilaufgaben herunter. Der Product Owner kann an dieser Stelle bereits festlegen, welche Kriterien erfüllt sein müssen, damit das Team die einzelnen Teilaufgaben besser bewerten kann. Wenn dieser Prozess im Vorfeld zum Sprint Planning stattfindet, kann dieses effizienter und schneller abgehalten werden. Ein Product Backlog Refinement sollte nicht mehr als 5 – 10% der gesamten Sprintdauer einnehmen.
In Teil III erzähle ich dir noch etwas zu den wichtigsten Scrum Begriffen. Hast du Fragen oder Anmerkungen zu den verschiedenen Scrum Meetings? Schreib sie mir gerne in die Kommentare oder auf Instagram.
