Was geschieht in einem Sprint und wann?
Die erfolgreiche Umsetzung von Scrum beinhaltet eine Reihe von wichtigen Zeremonien. Dazu gehören das Sprint Planning, das Sprint Review, das Daily Scrum, die Sprint Retrospektive uvm.
Häufig gibt es Unklarheiten darüber, wer an welchen Scrum Zeremonien teilnehmen sollte, wann sie stattfinden, wie lange sie dauern sollten, was die Zielsetzung der jeweiligen Zeremonie ist usw.
Diese Unklarheiten versuchen wir in diesem Artikel zu beseitigen:
Das Sprint Planning
Wenn der Sprint beginnt, wird auch das Sprint Planning durchgeführt. Es markiert also offiziell den Start des Sprints.
Das gesamte Scrum Team nimmt am Sprint Planning teil; d.h. sowohl das Entwicklungsteam als auch der Scrum Master und der Product Owner. Auch andere Personen können in seltenen Fällen an diesem Event teilnehmen, wenn Product Owner und Entwicklungsteam dies für angebracht halten. Wenn beispielsweise im kommenden Sprint Funktionalität entwickelt werden soll, die am besten von einem Fachexperten erklärt wird (der nicht gleichzeitig der Product Owner ist), kann es hilfreich sein, wenn diese Person beim Planning anwesend ist. In den meisten Fällen ist es jedoch am sinnvollsten, wenn diese Diskussionen außerhalb des eigentlichen Planning Meetings geführt werden.
Die Länge des Sprint Plannings ist proportional zur Länge des Sprints. Bei einem vierwöchigen Sprint sollte das Planning nicht länger als acht Stunden dauern; bei einem einwöchigen Sprint nicht länger als zwei Stunden – also max. zwei Stunden pro Sprintwoche.
Diese Beschränkung auf eine maximale Dauer eines Meetings nennt man auch Time Boxing. Ich empfehle Teams, möglichst in etwa der Hälfte der maximal erlaubten Time Box mit dem Sprint Planning fertig zu werden.
Als Input für das Sprint Planning bringt der ScrumMaster Informationen zur durchschnittlichen sowie aktuellen Velocity (Arbeitsgeschwindigkeit) mit. Der Product Owner bringt das Product Backlog oder zumindest die Backlog Items mit der höchsten Priorität ins Planning mit. Bei manchen Teams stellt der Product Owner im Planning auch schon ein vorläufiges Sprint-Ziel auf, das dann gemeinsam mit dem Team während des Plannings überarbeitet werden kann.
Das Ergebnis des Sprint Plannings ist ein informierteres und besser für die aufkommenden Arbeiten vorbereitetes Team. Weitere Ergebnisse des Plannings sind das Sprint Backlog und ein gemeinsam erstelltes Sprint-Ziel.
Daily Scrum / Daily Standup
Das Daily Scrum – u.a. auch Daily Standup genannt – ist eine kurze Zeremonie, die täglich stattfindet und bei der sich die Teammitglieder im Bezug auf ihre Arbeit synchronisieren. Mit Daily Scrums stellt man sicher, dass von den richtigen Leuten zur richtigen Zeit an den richtigen Dingen gearbeitet wird.
Jeden Tag werden von jedem Teammitglied die folgenden drei Fragen beantwortet:
Was habe ich gestern zur Erreichung des Sprint-Ziels getan?
Was werde ich heute zur Erreichung des Sprint-Ziels tun?
Habe ich Hindernisse/Probleme, die mich davon abhalten, und wenn ja welche?
Diese Fragen können auf unterschiedlichste Weise formuliert werden. Einige Teams beschreiben z.B. lieber, was sie erreicht haben, statt was sie getan haben.
Teilnehmer sollten der ScrumMaster, das Entwicklungsteam, und meines Erachtens auch der Product Owner sein.
In der Scrum Community gibt es einige Diskussionen darüber, ob der Product Owner nun am Daily Scrum teilnehmen sollte, oder nicht. Es dem Product Owner zu erlauben, sich nicht am Daily Standup zu beteiligen, kann ihn zu sehr vom Team abgrenzen. Ein „wir-vs-die anderen”-Gefühl existiert bereits in zu vielen Organisationen. Ich kann mir nicht vorstellen, warum ein Scrum Team oder deren Product Owner diese negative Einstellung noch weiter verstärken wollen würde.
Die Daily Scrums sind auf eine Dauer von max. 15 Minuten beschränkt. Das Ziel des Daily Scrums ist eine kurze Synchronisierung des Teams. Anders als beim Sprint Planning empfehle ich hier nicht, bereits in der Hälfte der vorgesehenen Zeit fertig zu werden. Für die meisten Teams reichen 5-7 Minuten einfach nicht aus, um echte Probleme anzusprechen oder zu verstehen, welche Arbeiten erledigt wurden. Wenn die Daily Scrums zu sehr gekürzt werden, werden sie schnell zur Routine mit Aussagen wie „Gestern habe ich XY gemacht. Heute mache ich dies und jenes. Ich habe keine Impediments.”
Es gibt keine formellen Ergebnisse der Daily Scrums, außer der verbesserten Koordination der Arbeiten im Entwicklungsteam.
Sprint Review
Das Sprint Review findet am letzten Tag des Sprints statt. Product Owner, ScrumMaster und Entwicklungsteam sollten dabei anwesend sein sowie die jeweiligen Stakeholder. Welche Stakeholder dabei sein sollten, ändert sich von Sprint zu Sprint und hängt davon ab, was im Sprint geliefert wurde.
Das Sprint Review hat eine Time Box von maximal vier Stunden für einen vierwöchigen Sprint. Entsprechend kürzer sind die Time Boxes für kürzere Sprints, z.B. eine Stunde für einen einwöchigen Sprint.
Im Sprint Review sollen alle Product Backlog Items gezeigt werden, die der Definition of Done entsprechen. Das bedeutet, dass keine Arbeiten gezeigt werden, an denen noch gearbeitet wird, die also noch nicht fertiggestellt sind. Manchmal kann es natürlich durchaus sinnvoll sein, eine Ausnahme von dieser Regel zu machen.
Die Demonstration fertiggestellter Funktionalität ist die zentrale Aktivität eines typischen Sprint Review Meetings. Die meisten Teams nehmen sich jedoch auch Zeit, um Fortschritte und eventuelle Probleme zu besprechen.
Das Ziel des Review Meetings ist, Feedback zu den Dingen einzuholen, die während des Sprints entwickelt wurden. Der Product Owner nimmt jegliches Feedback entgegen und kann anhand dieses Feedbacks, wenn nötig, das Product Backlog anpassen. Das Ergebnis eines Sprint Reviews ist demnach ein überarbeitetes Product Backlog.
Sprint Retrospektive
In der Sprint Retrospektive haben die Teammitglieder die Gelegenheit, zu überlegen, wie sie ihre Arbeitsweise verbessern können. Das kann zum Beispiel bedeuten, dass sie die Art und Weise, wie sie Scrum umsetzen, verändern möchten und dann z.B. die Sprintlänge anpassen. Die Retrospektive kann aber auch generelle Aspekte der Zusammenarbeit abdecken, wie z.B. Morgens keine Meetings mehr anzusetzen oder festzulegen, welche Themen man bei Slack besprechen kann und welche man in einer persönlichen Konversation klären sollte.
An der Sprint Retrospektive sollte das gesamte Team teilnehmen – d.h. das Entwicklungsteam, der ScrumMaster und der Product Owner. Alles andere würde nur zu einer Spaltung im Team führen. Ein gutes agiles Team sollte jegliche Verhaltensweisen vermeiden, die zu einem „wir-vs-die-anderen”-Mindset führen.
Außer dem Willen zur Verbesserung bedarf es bei der Sprint Retrospektive keines weiteren Inputs. Ergebnis der Retrospektive sollte eine Liste mit Änderungen bzw. Verbesserungsvorschlägen sein, die das Team umsetzen möchte.
Die Timebox für eine Retrospektive liegt bei max. 3 Stunden. Ab und zu kann es sein, dass sie etwas länger dauert, aber in den meisten Fällen werden Teams damit in unter einer Stunde fertig.
Product Backlog Refinement
Das Product Backlog Refinement soll dafür sorgen, dass die Items ganz oben im Backlog bereit sind für den nächsten Sprint. Das kann bedeuten, dass man Details zu vorhandenen Items hinzufügt, dass man Einschätzungen vornimmt, gewisse Items entfernt, Prioritäten neu ordnet, Backlog Items in kleinere Items aufsplittet oder neue Items erstellt.
Auch wenn das Refinement des Backlogs an sich notwendig ist, heißt das nicht, dass ein Team dies als offizielle Zeremonie tun muss oder dass es in jedem Sprint gemacht werden muss. Die meisten Teams führen jedoch regelmäßig Backlog Refinement Meetings durch, typischerweise einmal pro Sprint oder Woche.
Eine gute Richtlinie ist, dass ein Team nicht mehr als 10% seiner insgesamt verfügbaren Zeit für das Backlog Refinement aufwenden sollte – sowohl im Meeting selbst als auch in daraus entstehenden späteren Diskussionen.
Bei den meisten Teams nehmen sowohl alle Mitglieder des Entwicklungsteams sowie der Product Owner und der ScrumMaster an den Meetings teil. Sofern ein Team nicht gerade die Product Backlog Items in seinen Refinement Meetings einschätzt, denke ich, dass etwa die Hälfte bis zwei Drittel des Entwicklungsaufwandes ausreichen und das Meeting so für das Team möglichst kurz gehalten werden kann.
Das einzige, was zum Refinement mitgebracht werden muss, sind die obersten Items des Product Backlogs. Ergebnisse des Refinements sind kleinere Product Backlog Items, die sich besser für den nächsten Sprint eignen, sowie ein besseres Verständnis einiger Product Backlog Items.
Einschätzung des Backlogs
Wie oben bereits erwähnt, schätzen viele Teams ihre Product Backlog Items bereits während des Refinement Meetings ein. Das ist die Idealvorstellung und wenn möglich nimmt das gesamte Entwicklungsteam am Backlog Refinement teil.
Wenn nur ein Teil des Teams am Refinement teilnimmt, treffen sich die Teammitglieder einmal pro Sprint, um alle neuen Arbeiten einzuschätzen, für die der Product Owner eine Einschätzung benötigt.
Bei den meisten Teams sollten diese Einschätzungsmeetings sehr kurz gehalten werden. Die Teams sollten nämlich weder zu viele neue Product Backlog Items erzeugen, noch eine Flut an neuen Items von außen erhalten. Die Arbeiten, die eingeschätzt werden sollen, sollten entweder sehr wichtig oder neue oder existierende Items sein, die aufgesplittet wurden, um besser in den anstehenden Sprint zu passen.
Ich führe das Product Backlog Estimating gerne direkt nach einem Daily Scrum und ein paar Tage vor Ende des Sprints durch. Das ist spät genug, sodass die meisten neuen Items bereits identifiziert wurden, und früh genug für den Product Owner, um die Priorisierung anhand der neuen Informationen durch die Einschätzungen ändern zu können.
Ich empfehle nicht, die Items während des Sprint Plannings einzuschätzen. Dann ist es nämlich zu spät für den Product Owner, die Priorisierung anhand der Einschätzungen anzupassen. Es führt außerdem dazu, dass die Teammitglieder mehr Zeit mit den Einschätzungen verbringen, als sie sollten. Also, Product Backlog Items nicht während des Sprint Plannings durchführen.
Priorisierung
Bevor ein neuer Sprint beginnt, stellt der Product Owner sicher, dass alle Items ganz oben im Product Backlog priorisiert wurden. Laut dem Oxford American Dictionary bedeutet priorisieren: „Aufgaben, Probleme etc. nach deren Wichtigkeit in eine Reihenfolge zu bringen, damit man sich mit den wichtigsten davon zuerst auseinandersetzen kann.”
Das heißt, dass es nicht ausreicht, zu sagen: „Sie werden alle benötigt.” Oder wie ein Product Owner mir einmal erzählte „Sie heißen nicht umsonst Anforderungen; denn sie sind erforderlich.”
In den meisten Fällen wird es keine offizielle Zeremonie für die Priorisierung geben. Es ist eher etwas, das der Product Owner nach Gesprächen mit den Stakeholdern zur Klärung ihrer Bedürfnisse und Wünsche alleine tut.
Die Priorisierung sollte so spät wie möglich im Sprint stattfinden aber auf jeden Fall sollte sie vor dem nächsten Sprint erledigt sein. Das kann häufig bedeuten, dass sie an einem der beiden letzten Tage des Sprints durchgeführt wird.
Die Priorisierung ist normalerweise nicht besonders zeitaufwändig, da der Product Owner typischerweise den Feinschliff erst im Laufe des Sprints anhand von neuen Erkenntnissen vornimmt, statt von Anfang an das gesamte Backlog bis ins Detail zu priorisieren.
Die Meetings in einem Sprint
Wie Sie sehen, gibt es eine Reihe von wichtigen Zeremonien in Scrum, die man gewissenhaft durchführen sollte. Hoffentlich hat Ihnen dieser Beitrag eine bessere Übersicht gegeben und zu mehr Klarheit im Alltag mit Ihrem Scrum Team verholfen. Wenn Sie noch mehr erfahren möchten, sind unsere Scrum Trainings genau das Richtige für Sie.
Dieser Beitrag stammt aus dem Blog von Mike Cohn und wurde von uns ins Deutsche übersetzt.