In diesem einleitenden Artikel betrachten wir die Mechanik eines Sprints und wie von Teammitgliedern erwartet wird, dass sie zusammenarbeiten, um ein Inkrement in Release-Qualität zu erstellen.

Der erste Tag: Sprintplanung

Das gesamte Team, einschließlich des Product Owners, trifft sich am ersten Tag des Sprints und führt eine Sprintplanungssitzung durch. Dies ist das erste, was passiert, sobald der Sprint beginnt.

Vorbereitung

Sprintplanung sollte vorbereitet sein. Die wichtigste Vorbereitung besteht darin, sicherzustellen, dass das Product Backlog auf einen angemessenen Detaillierungsgrad mit Schätzungen und Akzeptanzkriterien verfeinert wurde (dies ist der Zweck der Verfeinerung des Product Backlogs). Als nächstes sollte der Product Owner die Arbeit am Product Backlog bestellt haben und eine allgemeine Vorstellung davon haben, wie ein wertvolles Sprint-Ziel mit dem Team ausgehandelt werden kann. Die Optionen für die Aushandlung eines Ziels sollten auch bei der Verfeinerung berücksichtigt und in der Backlog-Reihenfolge berücksichtigt worden sein. Außerdem sollte das Team eine Vorstellung von seiner Kapazität für diesen Sprint haben, dh wie viel Arbeit es zu übernehmen glaubt. Möglicherweise können sie ihre Erfahrungen mit früheren Sprints nutzen, um die Größe dieses Budgets zu ermitteln.

Planen Sie zuerst den Wert, der geliefert wird

Jeder Sprint sollte zu einem wertvollen Inkrement der abgeschlossenen Arbeit führen, fit und bereit für die sofortige Veröffentlichung. Der Product Owner ist vollständig dafür verantwortlich, was „Wert“ bedeutet, und sollte das Product Backlog so angeordnet haben, dass der Wert vom Team Sprint für Sprint maximiert werden kann. Das erste, was das Team tun muss, ist daher zu planen, welche Elemente aus dem Product Backlog in diesem Sprint bearbeitet werden sollen, damit am Ende der beste Wert erzielt werden kann.

Um dies zu tun, arbeitet das Team mit dem Product Owner zusammen, um die wertvollsten Elemente aus dem Product Backlog auszuwählen, die zu seiner projizierten Kapazität für den Sprint passen. Denken Sie daran, dass jedes Element im Product Backlog vom Team geschätzt werden sollte, damit es ungefähr weiß, wie viel Arbeit wahrscheinlich erforderlich ist.

Stellen Sie sicher, dass Sie ein Sprint-Ziel vereinbaren

Diese Auswahl von Arbeiten sollte zusammenhängend sein und nicht nur eine Gruppierung von nicht verwandten und unterschiedlichen Elementen. Denken Sie daran, dass ein Sprint eine zeitlich begrenzte Gelegenheit ist, etwas Bedeutendes zu erreichen. Zum Beispiel kann am Ende des Sprints ein kohärentes Feature bereitgestellt oder ein signifikantes Risiko gemindert worden sein. Das Sprint-Ziel ist ein einfacher Ausdruck dieses Zwecks, der übergeordneten Bedeutung der ausgewählten Arbeit und der Kohärenz hinter der Auswahl.

Ein gutes Sprint-Ziel ermöglicht es dem Team, Fokus und Engagement zu demonstrieren und die Zusammenarbeit und die Neuplanung der Arbeit zu ermöglichen, damit sie erreicht wird.

Als nächstes planen Sie, wie die Arbeit erledigt wird

Ein Sprint Backlog ist mehr als nur eine Auswahl von Arbeiten mit einem Endziel. Es ist auch ein Plan, wie dieses Ziel erreicht wird und wie die damit verbundene Arbeit ausgeführt wird. Dies kann durch die Identifizierung und Bestellung der technischen Aufgaben erfolgen, die wahrscheinlich beteiligt sind. In der Tat ist das Sprint Backlog ein Plan zur Erreichung des Sprintziels und eine Prognose der zu erledigenden Arbeit.

Der Product Owner muss für diesen Teil der Sprintplanung nicht anwesend sein, da es Sache des Teams ist, diese Prognose auf technischer Ebene zu planen. Der Product Owner sollte jedoch, wenn auch nur aus der Ferne, zur Verfügung stehen, um alle Fragen des Teams zu beantworten und um den Umfang der Arbeit zu klären. Wenn während des Sprints mehr als ein Release erwartet wird, sollte dies mit dem PO abgestimmt und im Sprint Backlog berücksichtigt werden.

Am Ende der Sprintplanung sollte ein Team sicher sein, dass es eine gute Prognose der Arbeit erstellt hat, die erforderlich ist, um das Sprintziel zu erreichen. Es wird diesen Plan im Sprint Backlog erfasst haben, den das Team vollständig besitzt. Das Team sollte in der Lage sein, diesen Plan sofort und mit einem klaren Verständnis – wie z. B. einem Sprint-Burndown – umzusetzen, wie viel Arbeit zu einem bestimmten Zeitpunkt noch übrig ist.

Jeden Tag, jeden Tag

Sobald das Team sein Sprint Backlog geplant hat, kann es mit der Arbeit beginnen. Wenn sie Dinge als Aufgaben geplant haben, werden sie als Team zusammenarbeiten, um sicherzustellen, dass diese Aufgaben erledigt werden. Sie können ihren Fortschritt mithilfe ihres Task Boards und ihres Sprint-Burndowns der verbleibenden Arbeit verfolgen.

Jedes Teammitglied wird sicher sein, das Scrum Task Board und den Sprint Burndown auf dem neuesten Stand zu halten, damit sich andere auf die Informationen verlassen können. Ein Informationstrahler sollte immer die Wahrheit sagen.

Halten Sie ein Daily Scrum ab

Jeden Arbeitstag trifft sich das Entwicklungsteam zur gleichen Zeit und plant, was es tun wird, um es dem Sprintziel näher zu bringen. Dieses Meeting wird als Daily Scrum bezeichnet und sollte niemals länger als 15 Minuten dauern.

Nur Mitglieder des Entwicklungsteams sollten teilnehmen, da der Arbeitsplan vollständig ihnen gehört. Es ist eine zeitlich begrenzte Gelegenheit, das Sprint-Backlog aufgrund neuer Entdeckungen und Erkenntnisse während des Sprints neu zu planen. Das ganze Team sollte mitmachen. Jedes Teammitglied sollte in der Lage sein, Folgendes zu berücksichtigen:

• Was sie gestern getan haben, um dem Team zu helfen, das Sprintziel zu erreichen
• Was sie heute tun wollen, um dem Team zu helfen, das Sprintziel zu erreichen
• Alle Hindernisse, die ihnen im Weg stehen

Am Ende des Daily Scrum sollte das Team einen klaren Plan für die nächsten 24 Stunden haben und verstehen, wie sie zusammenarbeiten müssen, um es zu erreichen. Sie sollten auch eine Liste aller Hindernisse haben, die die Aufmerksamkeit des Scrum Masters erfordern.

Verfeinern des Product Backlogs

In Scrum ist die Verfeinerung des Product Backlogs kein formelles Ereignis, sondern eine fortlaufende Aktivität – der Prozess des Hinzufügens von Details, Bestellungen und Schätzungen zu Product Backlog-Elementen wie User Stories. Es liegt an den Scrum-Teams selbst zu entscheiden, wie oft sie dies tun, obwohl es für sie sicherlich eine gute Idee ist, dies in ihre tägliche Routine einzubauen. Die Verfeinerung sollte während eines Sprints nicht mehr als 10% der Gesamtzeit eines Teams in Anspruch nehmen. Für die meisten Teams kann eine halbe Stunde pro Tag ausreichend sein, obwohl einige es vorziehen, ein oder zwei Stunden ein paar Mal pro Woche zu verbringen. Wichtig ist, dass das Product Backlog rechtzeitig verfeinert wird, damit die Sprintplanung ungehindert erfolgen kann. Das gesamte Team, einschließlich des Product Owners, sollte teilnehmen.

Eine Verfeinerungssitzung beginnt in der Regel damit, dass der Product Owner dem Team das aktuelle Product Backlog vorstellt. Das Backlog kann in einer Reihe von Formen gehalten werden, z. B. in einem elektronischen Scrum Board oder einem anderen Tool für die Zusammenarbeit, oder es kann sich einfach um eine Tabelle handeln. Ein Projektor oder ein gemeinsam genutzter Bildschirm kann sehr nützlich sein.

Das Team beginnt ganz oben im Product Backlog und arbeitet sich nach unten, wobei jedes Element der Reihe nach verfeinert wird. Sie werden jeden einzelnen untersuchen und seinen Umfang sowie die Akzeptanzkriterien besprechen, die für seine Fertigstellung erforderlich sind. Jeder Artikel wird dann mit einer Technik wie Planning Poker geschätzt. Ein großes Element kann in kleinere unterteilt werden, die mehr Details erfassen. Epics können beispielsweise in User Stories zerlegt werden.

Das Team stoppt, sobald die Zeitbox der Sitzung abgelaufen ist. Sie werden beim nächsten Mal wieder dort beginnen, wo sie aufgehört haben, und schließlich wieder ganz oben beginnen, damit der Rückstand auf dem neuesten Stand bleibt.

Immer zusammenarbeiten

In der agilen Praxis arbeiten Teammitglieder niemals isoliert – wenn sie es täten, wären sie kein Team. Tatsächlich ist Teamwork so wichtig, dass die Rolle eher Entwicklungsteam als Entwickler ist.

Dies bedeutet, dass jedes Mitglied des Entwicklungsteams den ganzen Tag über mit seinen Kollegen zusammenarbeiten muss, da sie gemeinsam für den Arbeitsfortschritt verantwortlich sind. Alle Probleme oder Misserfolge gehören dem Team gemeinsam, ebenso wie deren Erfolge. Die Zusammenarbeit ist nicht auf Ereignisse wie das Daily Scrum beschränkt, sondern gilt für alles, was das Team während des gesamten Sprints tut.

Beispiele für Zusammenarbeit sind:

• Kollegen helfen, laufende Arbeiten abzuschließen, bevor sie neue Arbeiten aus einem Rückstand einbringen
• Pair Programming, z. B. abwechselnd die Tastatur benutzen und sich gegenseitig helfen und die Arbeit überprüfen
• Peer Review
• Um Hilfe bitten und daran interessiert sein, sie zu geben
• Dorthin gehen, wo die Arbeit ist, und helfen, anstatt darauf zu warten, dass die Arbeit an sie übergeben wird
• Sicherstellen, dass alle Arbeiten tatsächlich der Definition von Done
• Ein Scrum aufrufen, um Probleme zu lösen, die die sofortige Aufmerksamkeit des Teams erfordern
• Hindernisse für der Scrum Master, damit sie rechtzeitig behandelt werden können
• Aktualisierung eines Scrum Task Boards und eines Burndown-Diagramms, damit die Informationen auf dem neuesten Stand sind und auf die man sich verlassen kann
• Skill- und Wissensaustausch

Der letzte Tag: Review und Retrospektive

Halten Sie einen Sprint Review ab

Wenn ein Team effizient zusammengearbeitet hat, wird es haben zusammengearbeitet, um das Sprint-Ziel zu erreichen, Risiken zu managen und ihre Pläne nach Bedarf anzupassen. Sie haben die Kontrolle während des gesamten Sprints durch ein gleichmäßiges Abbrennen der verbleibenden Arbeit demonstriert, wobei jedes Mitglied es als seine persönliche Verantwortung ansah, die laufenden Arbeiten abzuschließen. Sie haben ein wertvolles Inkrement, das sie dem Product Owner und allen eingeladenen Stakeholdern demonstrieren können. Ein Review ist etwas, worauf sich ein Team freuen sollte.

Es ist auch etwas, worauf sich ein Team vorbereiten muss. Es muss genügend Zeit für eine Demonstration der geleisteten Arbeit eingeräumt werden. Zu diesem Zweck können Aufgaben in einem Sprint Backlog geplant werden, um sicherzustellen, dass die Überprüfung der geleisteten Arbeit und dem jetzt verfügbaren Wert gerecht wird. Wenn der Product Owner der Meinung ist, dass es eine gute Idee wäre, Stakeholder einzuladen, sollten diese Einladungen gesendet worden sein. Die Überprüfung ist eine Gelegenheit, die geleistete Arbeit zu feiern und ihre Leistungen zu präsentieren, So wird Vertrauen geweckt und eine fortgesetzte Investition in das Team könnte gerechtfertigt sein.

Ein Sprint Review ist auch eine Inspect-and-Adapt-Möglichkeit. Es ist ein guter Zeitpunkt für den Product Owner, um zu erklären, wie gut das Produkt funktioniert, um Feedback aus erster Hand von eingeladenen Parteien zu erhalten und Lehren zu ziehen, die zur weiteren Verbesserung des Product Backlogs verwendet werden könnten. Wenn aus irgendeinem Grund keine Arbeiten abgeschlossen wurden, wird dies auch im Product Backlog überprüft und neu geschätzt, um eine mögliche Planung für zukünftige Sprints zu ermöglichen.

Dann eine Sprint Retrospektive durchführen

Der Sprint Review betrachtete das Produkt und den gelieferten Wert, die geleistete Arbeit und ehrlich und offen jede Arbeit, die nicht getan wurde, aus welchem Grund auch immer.Das nächste, was zu tun ist, ist eine Sprint Retrospektive durchzuführen. Eine Retrospektive betrachtet den Prozess, den das Team verfolgt. Arbeiten sie so effektiv wie möglich? Im Allgemeinen ist es am besten, die Retrospektive unmittelbar nach der Überprüfung durchzuführen, da erstere Ideen zur Berücksichtigung in letzterem einbringen können.

Das gesamte Entwicklungsteam, der Product Owner und der Scrum Master müssen an der Retrospektive teilnehmen, da jeder gemeinsam für den Erfolg der Teamarbeit verantwortlich ist. Es ist wirklich wichtig, eine freie und offene Sitzung zu haben, die alle Probleme auf den Punkt bringt und Maßnahmen identifiziert, die helfen, sie zu lösen. Eine Retrospektive kann mit folgender Erklärung beginnen:

„Unabhängig davon, was wir entdecken, verstehen und glauben wir wirklich, dass jeder den besten Job gemacht hat, den er konnte, angesichts dessen, was er zu diesem Zeitpunkt wusste, seiner Fähigkeiten und Fertigkeiten, der verfügbaren Ressourcen und der aktuellen Situation.“

In einem „Retro“hat jeder die gleiche Stimme. Ein Ansatz, den der Scrum Master erleichtern kann, besteht darin, Folgendes zu identifizieren:

• Dinge, die gut gelaufen sind
• Dinge, die nicht so gut gelaufen sind
• Ideen für Verbesserungen
• Shout-outs für Teammitglieder, die etwas Außergewöhnliches getan haben

Die Festlegung einer Zeitlinie kann dazu beitragen, die Erinnerungen der Teilnehmer an wichtige Ereignisse während des Sprints zu wecken.