Scrum-Ereignisse: Zeitboxen, Sprint-Planung, tägliches Aufstehen und Verfeinern des Rückstands

scrum events time boxing

Einführung in Scrum Events:

In unseren früheren Tutorials haben wir Scrum und seine Struktur besprochen.

Und unser vorheriges Tutorial hat alles darüber erklärt Scrum-Artefakte im Detail.

Wir wissen, wer das Scrum-Team bildet und welche unterschiedlichen Artefakte während des gesamten Prozesses entwickelt werden. Wir haben jetzt einen starken Hintergrund geschaffen. Lassen Sie uns daher Scrum einen Schritt voraus sein und die wichtigsten Ereignisse / Zeremonien diskutieren, die den Scrum-Prozess ausmachen.

In diesem Tutorial werden wir versuchen zu verstehen, was jedes Scrum-Ereignis bedeutet, was die wesentlichen Funktionen sind und wie wir sie im Detail organisieren.

Was du lernen wirst:

• Überblick
• Arten von Scrum-Ereignissen
• Was ist Zeitboxen?
• Die Sprint-Planung
• Das tägliche Aufstehen
• Der Sprint Review
• Die Sprint-Retrospektive
• Verfeinerung des Rückstands
• Fazit
• Literatur-Empfehlungen

Überblick

Während der Arbeit an einem Scrum-basierten Projekt durchläuft das Scrum-Team eine Reihe von Scrum-Zeremonien.

Einige nennen sie Scrum-Zeremonien oder -Ereignisse, andere nennen sie Rituale oder Versammlungen. Unabhängig von den hier verwendeten unterschiedlichen Terminologien bleibt das Ziel jedes Scrum-Ereignisses dasselbe. Jedes der Scrum-Ereignisse hilft im Wesentlichen bei der Durchführung und Überwachung der Sprint-Arbeit.

Arten von Scrum-Ereignissen

Jede Scrum-Zeremonie ist eine persönliche Angelegenheit / Versammlung, die vom Scrum-Meister für die engagierten Gruppen organisiert wird. Abgesehen vom Kernteam können an einigen Besprechungen Stakeholder, Liefermanager oder sogar der Kunde selbst beteiligt sein. Diese Besprechungen sind zeitlich begrenzt und müssen daher innerhalb des festgelegten Zeitrahmens abgeschlossen werden.

Ziel jedes Treffens ist es, die Teilnehmer zu versammeln und sie über die anstehende Arbeit diskutieren zu lassen. Von jedem Teilnehmer wird erwartet, dass er konzentriert, engagiert und partizipativ bleibt.

Es wird als Gelegenheit gesehen, sich zu unterhalten, zu untersuchen und das Feedback der geleisteten Arbeit abzurufen. Im Gegensatz zu den normalen Meetings sind die Scrum-Events ergebnisorientiert, zeitlich begrenzt, zielgruppenorientiert und haben ein spezifisches Ziel, das auf jedes einzelne ausgerichtet ist.

Was ist Zeitboxen?

Timeboxing ist eine der wichtigsten Funktionen, die mit jedem Scrum-Ereignis verbunden sind. Von den Teilnehmern wird erwartet, dass sie die für die einzelnen Veranstaltungen vorgesehene Zeit kennen und respektieren. Die Veranstaltungen können nicht verlängert, sondern verkürzt werden, wenn die Ziele des Treffens bereits erreicht wurden.

Scrum Master, der auch als Moderator für alle Scrum-Events fungiert, stellt sicher, dass jeder die Bedeutung des Zeitboxens versteht, und erinnert ihn immer wieder daran, sich auf das Ziel des Meetings zu konzentrieren, um die besten Ergebnisse und zeitlichen Ergebnisse mit Abweichungen zu erzielen.

Die Zeitbox für eine Veranstaltung sollte nicht idealerweise verlängert werden. Da wir jedoch wissen, dass es beim Scrum nicht um die Regeln geht, kann die Zeit auf eine bestimmte Länge verlängert werden, wenn jeder Teilnehmer zustimmt.

Wie bestimmen wir die Zeitbox für jedes Scrum-Ereignis?

Das Zeitfeld für Scrum-Ereignisse ist direkt proportional zur Länge des Sprints. Die einzige Ausnahme von dieser Regel ist jedoch Daily Standup mit einem festen Zeitrahmen von 15 Minuten, unabhängig von der Sprintlänge.

Es gibt Standardzeitrahmen für jedes Ereignis basierend auf der Sprintlänge. Das Team hat jedoch die Freiheit, den Zeitrahmen für diese Veranstaltungen anhand ihrer Anforderungen festzulegen.

Lassen Sie uns mehr von diesen Konzepten verstehen, indem wir jedes Scrum-Ereignis im Detail diskutieren.

Die Sprint-Planung

Als Voraussetzung für diese Zeremonie sollte der Product Owner ein stabiles priorisiertes Product Backlog mit User Stories erstellen, bevor er zur Besprechung kommt. Die User Stories sollten wohlgeformt und klar genug sein, damit das Team sie verstehen kann.

Der Product Owner kann die Stakeholder, Kunden, Designer und den Scrum Master um Hilfe bitten, um das Product Backlog zu entwickeln.

Es ist obligatorisch, dass eine User Story Akzeptanzkriterien enthält. Das Team ist berechtigt, eine User Story ohne die Akzeptanzkriterien abzulehnen.

Zweck

Sprint-Planung ist die erste Zeremonie beim Starten eines Sprints. Der Zweck des Sprint-Planungsmeetings besteht darin, ein Sprint-Ziel zu erstellen, User Stories aus dem Product Backlog in das Sprint Backlog auszuwählen und diese ausführlich zu diskutieren.

Das Team trifft sich in einem Besprechungsraum mit dem Product Owner und dem Scrum Master, wo der Product Owner die User Stories präsentiert, die für den nächsten Sprint ausgewählt werden sollen.

Das Team kann so viele Fragen stellen, wie es möchte, um mehr über die Geschichte zu erfahren. Es liegt in der Verantwortung des Product Owners, die Fragen zu beantworten. Das Team könnte die Geschichte auch wegen ihrer Vollständigkeit und Eignung in Frage stellen.

Wenn zusätzliche Informationen in der Story erforderlich sind oder eine unvollständige Abhängigkeit bestehen oder sich als unvollständig herausstellen, kann das Team diese Story ablehnen.

Nachdem die Zweifel ausgeräumt wurden und das Team genau weiß, wie viel Arbeit erforderlich ist, um eine Story fertigzustellen, schätzt das Team die Story Points und gibt sie jeder User Story.

In ähnlicher Weise werden die anderen Geschichten diskutiert und geschätzt. Das Team wählt nun die Geschichten aus dem oberen Bereich des priorisierten Produkt-Backlogs in das Sprint-Backlog aus, von denen es glaubt, dass sie sie aufgrund ihrer früheren Geschwindigkeit im Sprint festschreiben und abschließen können.

Die Geschwindigkeit wird durch die Gesamtzahl der Story-Punkte bestimmt, die in einem durchschnittlichen Sprint absolviert wurden. Die Geschwindigkeit wird basierend auf den historischen Sprints und durch Mittelung berechnet. Je mehr Sprints wir absolvieren, desto stabiler ist die Geschwindigkeit für ein Team.

Viele Teams verwenden Planning Poker-Karten für die Story-Schätzung. Die gebräuchlichste Schätzmethode ist das Zeigen von Geschichten mithilfe der Fibonacci-Reihe. Die Fibonacci-Reihe ist eine Reihe von Zahlen, bei der jede nächste Zahl in der Reihe durch Addition der beiden vorherigen Zahlen gebildet wird.

Fibonacci-Serie - 1, 1, 2, 3, 5, 8, 13 und so weiter.

Die User Stories, die über 13 Story Points hinaus geschätzt werden, werden als sehr groß angesehen, um in einem einzigen Sprint abgeschlossen zu werden, und werden daher in kleinere logische User Storys zerlegt, die einzeln geschätzt werden können.

Während eines Sprint-Planungsmeetings erstellt das Team auch Aufgaben unter den User Stories, die für den Sprint ausgewählt wurden. Es wird nicht erwartet, dass das Team alle User Storys während der Sprint-Planung aufgibt, aber es reicht gerade aus, um sie zu starten. Der Rest der Aufgabe kann während des Sprints erledigt werden.

Das wichtigste Ergebnis eines Sprint-Planungsmeetings ist das Sprint-Ziel und das Sprint-Backlog, die aus den User Stories bestehen, zu deren Fertigstellung sich das Team verpflichtet hat.

Abgesehen von den User Stories kann es einige andere Arten von Elementen geben, die Teil des Sprint-Backlogs werden können.

• Spikes
• Technische Schulden
• Bugs

Spikes sind die Forschungsaufgaben, um eine Lösung zu finden, d. h. die Notwendigkeit, die durch die User Story selbst ausgelöst wird. Einige der Geschichten sind möglicherweise nicht einfach oder nicht technisch und erfordern daher mehr Analyse und Forschung. Daher wird eine Spitze erzeugt. Bei Bedarf kann auch ein POC enthalten sein.

Technische Schulden sind das Refactoring des vorhandenen Codes. Manchmal gibt es Situationen, in denen das Team den zuvor entwickelten Code überarbeiten muss, um den neuen Anforderungen gerecht zu werden.

Bugs In Scrum sind normalerweise die fehlenden oder neuen Anforderungen enthalten, die sich aus den akzeptierten User Stories ergeben, aber für die aktuellen Arbeitselemente relevant sind. Wenn dies nicht erforderlich ist, kann es sich tatsächlich um einen Fehler im System handeln, der während der vorherigen Sprints entdeckt wurde, aber nicht behoben wurde und in diesem Sprint priorisiert wurde.

Teilnehmer

Jeder im Scrum-Team ist Teil des Sprint Planning-Meetings. Niemand anderes als das Kernteam ist zur Teilnahme an dem Meeting eingeladen.

Das Sprint Planning Meeting wird vom Scrum Master organisiert und moderiert, aber der Product Owner stiehlt die Show.

Zeitkasten

Das Sprint-Planungsmeeting kann für einen zweiwöchigen Sprint bis zu einem halben Tag dauern. Das Zeitfenster für ein Sprint Planning-Meeting hängt direkt von der Länge des Sprints ab. Kürzer für einen kurzen Sprint und länger für einen langen Sprint.

Das Sprint Planning-Meeting spielt eine sehr wichtige Rolle in der gesamten Scrum-Architektur und wirkt sich direkt auf das zu entwickelnde Produkt aus. Daher sollte das Team so viel Zeit investieren, wie es für erforderlich hält, um alle User Stories im Detail zu diskutieren, und kann eine alternative Zeitbox vorschlagen, die zu ihnen passt.

Sobald der Zeitrahmen festgelegt und vereinbart ist, liegt es in der Verantwortung des Scrum Masters, das Team auf das Ziel zu konzentrieren und gleichzeitig die Zeit im Auge zu behalten.

Das tägliche Aufstehen

Zweck

Daily Standup ist ein Meeting, bei dem ein Überblick über die Gesundheit des Sprints gegeben wird. Es ist auch eine Plattform, um zu diskutieren, woran die anderen Teammitglieder arbeiten und ob etwas daran hindert, das Sprintziel zu erreichen.

Während eines täglichen Standup-Meetings teilt jedes Teammitglied den Status seines Fortschritts bei den Arbeitselementen mit, an denen es arbeitet. Sie würden auch die anderen Teammitglieder teilen und um Hilfe bitten, wenn Hindernisse ihre Fortschritte blockieren.

Während eines täglichen Standup-Meetings beantwortet jedes Teammitglied am Tisch nacheinander die folgenden drei Schlüsselfragen:

'Was haben Sie seit dem letzten täglichen Standup-Meeting getan?'

'Was planen Sie heute zu tun?'

Test-Website in verschiedenen Browsern online

'Gibt es ein Hindernis, das Ihre Arbeit blockiert?'

Von den anderen Teammitgliedern wird erwartet, dass sie aufpassen, wenn jemand den Status teilt, und bei Bedarf Hilfe anbieten. Sobald das letzte Teammitglied alle drei Fragen beantwortet hat, endet das Meeting dort.

Das tägliche Standup-Meeting gibt einen Überblick über den aktuellen Status und den Gesamtabschlussstatus der Iteration, an der sie gerade arbeiten. Scrum Master spielt eine sehr wichtige Rolle, um das Daily Standup-Meeting fokussiert und zeitlich begrenzt zu halten. Er ist auch dafür verantwortlich, die Hindernisse zu beseitigen, die das Team daran hindern, mit seinen User Stories fortzufahren.

Scrum Master muss auch sicherstellen, dass niemand anderes als das Kernteam Fragen stellt und den Status präsentiert. Er kann bei Bedarf schnelle Diskussionen über die User Stories zulassen, muss jedoch die ganze Zeit über auf dem Laufenden bleiben und kann jederzeit eingreifen und die Teammitglieder bitten, eine Diskussion offline zu führen.

Teilnehmer

Jeder kann an einem täglichen Standup-Meeting teilnehmen. Das Kernteam muss jedoch an der Besprechung teilnehmen und den Status seiner Arbeit darlegen.

Alle anderen Personen außerhalb des Teams, die über den Sprint-Fortschritt informiert werden möchten, können am täglichen Standup-Meeting teilnehmen, dürfen jedoch nicht den Status seiner Arbeit präsentieren oder die Mitglieder des Entwicklungsteams zu ihrer Arbeit befragen.

Nur die Mitglieder des Kernteams dürfen ihren Arbeitsfortschritt teilen, und von allen anderen wird erwartet, dass sie still zuhören.

Das tägliche Standup-Meeting sollte auch dann durchgeführt werden, wenn ein einzelnes Teammitglied anwesend ist.

Das Team kann das tägliche Standup-Meeting selbst durchführen oder den Scrum Master bitten, es für sie zu erleichtern.

Zeitkasten

Wie der Name schon sagt, findet täglich ein tägliches Standup-Meeting statt, und von den Teilnehmern wird erwartet, dass sie stehen, da es sich um ein kurzes Meeting von nur 15 Minuten handelt. Die Idee ist, sich an die Tagesordnung zu halten und nicht vom Fokus abzuweichen, daher wird das Treffen kurz gehalten. Das Halten des Meetings hilft den Leuten auch dabei, sich leicht darauf einzulassen, da es nur 15 Minuten dauert.

Das tägliche Standup-Meeting wird auch täglich zur gleichen Zeit und am gleichen Ort abgehalten, um die Verwirrung unter den Teilnehmern und den Aufwand für die tägliche Buchung der Meetingräume zu verringern. Von der Verwendung von Laptops, Desktops oder Mobiltelefonen wird während des Meetings dringend abgeraten.

Die Teams können entscheiden, wann das Daily Standup-Meeting stattfinden soll, und sich daran halten. Die normale Tendenz ist jedoch, die Besprechungen als erstes am Morgen abzuhalten. Für die Teams, die in verschiedenen Zeitzonen arbeiten, funktioniert der Anruf am Morgen möglicherweise nicht und sie können den Anruf am Nachmittag haben oder was auch immer am besten zu ihnen passt.

Der Scrum Master kann dem Team auch wichtige Neuigkeiten oder Aktualisierungen am Ende des Meetings mitteilen, wenn es die Zeit erlaubt, das Meeting jedoch nicht um jeden Preis verlängern darf.

Der Sprint Review

Zweck

Beim Sprint Review Meeting geht es darum, die geleistete Arbeit zu demonstrieren und Feedback und Buy-In zu sammeln. An einigen Stellen wird das Sprint Review-Meeting auch als Sprint Demo bezeichnet. Das Sprint Review Meeting wird normalerweise am Ende des Sprints, jedoch vor dem Sprint Retrospective Meeting durchgeführt.

Die ausgewählten Vertreter des Teams demonstrieren die aktuellen Sprint-Arbeitselemente. Normalerweise demonstriert der Entwickler, der an der User Story arbeitet, die Arbeit und antwortet auf die Fragen, die von jedem im Publikum gestellt werden.

Die User Stories, die basierend auf der Definition of Done erstellt werden, sind die einzigen Kandidaten für die Demonstration beim Sprint Review Meeting.

Der Product Owner spielt während des Sprint Review Meetings eine sehr wichtige Rolle. Er ist dafür verantwortlich, jede der demonstrierten User Storys anhand ihrer Akzeptanzkriterien zu bewerten und die Story zu akzeptieren oder abzulehnen.

Die akzeptierten Storys werden dann in das Done Increment integriert, das möglicherweise versandfähig ist. Wohin eine abgelehnte oder unvollständige Geschichte führen würde, ist der Anruf des Product Owners. Die abgelehnten Storys können Teil des nächsten Sprints werden oder in das Product Backlog verschoben werden, von wo aus sie erneut priorisiert werden.

Das wichtigste Ergebnis des Sprint Review-Meetings ist ein Gesamtbild des Projektabschlussdatums. Der Product Owner akzeptiert / lehnt die Story ab und die akzeptierten Storys werden dann in das Inkrement (das bei früheren Sprints erstellt wurde) als Ganzes integriert, um ein besseres Bild davon zu erhalten, wo wir bei der Fertigstellung des gesamten Produkts stehen.

Ein weiteres wichtiges Ergebnis des Sprint Review-Meetings ist, dass die Teammitglieder etwas über Schätzungen lernen. Die Anzahl der akzeptierten User Stories bestimmt die Anzahl der in einem Sprint erzielten Story Points.

Auf diese Weise kann das Team schrittweise Sprint für Sprint die Fähigkeit entwickeln, richtig zu schätzen und eine fundierte Entscheidung über die möglichen Story-Punkte zu treffen.

Es wird häufig beobachtet, dass solche Treffen Aufschluss über die unvollständigen Akzeptanzkriterien oder die neuen Anforderungen geben. Der beste Weg, um aus dieser Situation herauszukommen, besteht darin, die Geschichten zu schließen und als erledigt zu markieren, wenn sie alle Akzeptanzkriterien erfüllen, die ursprünglich während des Sprint-Planungstreffens vereinbart wurden.

Alles, was darüber hinausgeht, ist als neue Anforderung zu betrachten, und der Product Owner ist für diese Anforderungen für den zukünftigen Sprint verantwortlich.

Teilnehmer

Das Sprint Review Meeting wird von den Teammitgliedern besucht, einschließlich des Scrum Masters und des Product Owner. Andere Teilnehmer am Sprint Review Meeting sind die Stakeholder, Delivery Manager, Kunden / Endbenutzer oder alle, die daran interessiert sind, Teil des Sprint Review zu sein.

Zeitkasten

In einem idealen Szenario für einen zweiwöchigen Sprint verbringen wir ungefähr zwei Stunden im Sprint Review-Meeting. Dies kann je nach Länge des Sprints variieren. Für einen kürzeren Sprint kürzere Sprint Review und für einen längeren Sprint längere Sprint Review.

Wie bei anderen Besprechungen ist der Scrum Master dafür verantwortlich, die Dynamik der Besprechung aufrechtzuerhalten und sicherzustellen, dass die Aktivitäten (Demonstrieren der Geschichten, Beantworten der Fragen, Akzeptieren der Geschichten, notiertes Feedback usw.) in den festgelegten Zeitrahmen passen.

Die Sprint-Retrospektive

Zweck

Bei der Sprint-Retrospektive geht es darum, das zu verkörpern, was Agile sagt: Regelmäßige Überlegungen, wie man effektiver wird ’. Die Sprint-Retrospektive bietet dem gesamten Team die Möglichkeit, darüber nachzudenken und nachzudenken, wie der Sprint verlaufen ist und was getan werden muss, um die Prozesse zu improvisieren. Die Sprint-Retrospektive wird am Ende jedes Sprints durchgeführt.

Während eines Sprint Retrospective-Meetings kommt das gesamte Team zusammen und bespricht den gerade abgeschlossenen Sprint. Es wird erwartet, dass das Team transparent ist und ehrliche Meinungen abgibt, aber es gibt keine Schuldzuweisungen.

Denken Sie an das Ziel des Treffens, im Bereich der Improvisation einen Schritt voraus zu sein und das Team nicht zu halten, indem Sie die Spannung unter den Mitgliedern erhöhen.

Jedermann im Das Team wird voraussichtlich die vier grundlegenden Fragen beantworten:

Der Scrum Master bittet die Teammitglieder, ihre Punkte für jeden der Quadranten zu schreiben, wie oben in Haftnotizen angezeigt. An einigen Stellen werden Werkzeuge für den gleichen Zweck verwendet.

Was ging gut?

Die Teammitglieder geben einen oder mehrere Punkte für das, was im letzten Sprint gut gelaufen ist. Dieser Abschnitt kann auch als Gelegenheit genutzt werden, die anderen Teammitglieder für ihre gute Arbeit zu würdigen und anzuerkennen.

Was hast du gelernt?

Scrum wird als Gelegenheit gesehen, in jedem Sprint etwas Neues zu lernen. In diesem Bereich eines Quadranten sollen die wichtigsten Erkenntnisse und Erkenntnisse aus dem letzten Sprint besprochen werden.

Was ist nicht gut gelaufen?

In diesem Abschnitt erörtert das Team die Probleme und Hindernisse, mit denen sie beim letzten Sprint konfrontiert waren. Dieser Teil des Treffens ist in der Regel der fragilste, da die Leute möglicherweise Probleme aufwerfen, die die anderen unangenehm machen.

Es liegt in der Verantwortung des Scrum Masters, die Atmosphäre bei Bedarf zu beruhigen und die Menschen zu lehren, ihre Probleme auf konstruktive Weise anzusprechen, anstatt die Runden persönlicher Angriffe zu durchlaufen.

Wenn es einem Mitglied unangenehm ist, die Probleme vor den anderen Teamkollegen zu lösen, kann es später zum Scrum Master gehen und die Probleme besprechen.

MySQL vs SQL Server vs Orakel

Was könnte besser gemacht werden?

Dieser Teil des Meetings bietet allen Teammitgliedern die Möglichkeit, alle zuvor angesprochenen Probleme zu diskutieren und Wege zu ihrer Lösung zu finden. Jeder im Team ist herzlich eingeladen, Lösungen für das jeweilige Problem vorzuschlagen. Das Team entscheidet dann gemeinsam über die am besten geeigneten Lösungen.

Das Team sollte auch in Betracht ziehen, sich an die Dinge zu halten, die im Abschnitt 'Gut gelaufen' für die zukünftigen Sprints besprochen wurden, und diese Dinge können in Zukunft als integraler Bestandteil des Prozesses hinzugefügt werden.

Das Ergebnis des Sprint Retrospective-Meetings ist eine Liste von Aktionspunkten, auf die sich die Teilnehmer geeinigt haben, um den Prozess für den bevorstehenden Sprint zu verbessern.

Teilnehmer

Das gesamte Scrum-Team einschließlich des Scrum-Masters und des Product Owner. Im Gegensatz zu einem täglichen Standup-Meeting beteiligen sich der Scrum Master und das Produkt jedoch auch an der Bereitstellung ihrer Inputs und Rückblicke.

Wie das tägliche Standup-Meeting wird auch das Sprint Retrospective-Meeting vom Scrum Master geleitet. Scrum Master stellt sicher, dass jeder im Team, einschließlich sich selbst, die Möglichkeit erhält, sowohl die positiven als auch die negativen Aspekte zu öffnen und zu sprechen.

Beachten Sie, dass Teilnehmer außerhalb des Teams nicht zum Sprint Retrospective Meeting eingeladen werden. Die Sprint-Retrospektive wird als eine kleine persönliche und emotionale Umgebung angesehen, in der sich die Teammitglieder ohne zu zögern öffnen und die Probleme diskutieren können, mit denen sie während des letzten Sprints konfrontiert waren.

Zeitkasten

Es wird zu Recht gesagt, dass alle Scrum-Zeremonien zeitlich begrenzt sind und ihre Zeitbox von der Länge des Sprints abhängt. Für einen zweiwöchigen Sprint ist es jedoch ideal, ein Sprint Retrospective-Meeting für 2 Stunden abzuhalten.

Wenn wir jedoch die Sprint-Retrospektive als Gelegenheit betrachten, zu kommunizieren, einen Rückblick zu geben und sich für die Verbesserungen einzusetzen, ist es sehr gerechtfertigt, genügend Zeit für das Meeting einzuräumen, um nicht die wichtigen Gesichtspunkte und Erkenntnisse zu verlieren.

Daher ist es gut, die Besprechung zeitlich festzulegen, sie sollte jedoch nicht auf Kosten der Kommunikation und des Fortschritts erfolgen. Ein weiteres sehr wichtiges Ereignis in Scrum ist die Backlog-Verfeinerung. Nehmen wir uns einen kurzen Moment Zeit, um etwas Licht ins Dunkel zu bringen.

Verfeinerung des Rückstands

Die Backlog-Verfeinerung, die auch als Backlog-Pflege bezeichnet wird, ist eine Besprechung, in der die User Stories im Product Backlog besprochen werden, die möglicherweise Teil des nächsten Sprints sind. In einem Backlog-Verfeinerungsmeeting sitzt das gesamte Team zusammen und diskutiert die User Stories, um ihre Eingaben zu liefern.

Die Grundidee besteht darin, das Product Backlog für den bevorstehenden Sprint vorzubereiten und sicherzustellen, dass die User Stories zur Auswahl bereit sind. Das Backlog-Verfeinerungsmeeting wird während des n-1-Sprints organisiert, um die Auswahl der im n-Sprint ausgewählten Elemente vorzubereiten.

Fazit

Damit sind wir am Ende dieses Tutorials zu „Scrum Events“ angelangt, das zum Lesen unbedingt benötigt wird. Scrum Events ist bei weitem das wichtigste und bedeutendste Thema der Scrum-Reihe.

In diesem Tutorial haben wir alle fünf Scrum-Ereignisse besprochen, d.h. Sprint, Sprint-Planung, tägliches Aufstehen, Sprint-Überprüfung und Sprint-Retrospektive . Jedes andere Ereignis als das tägliche Aufstehen hat einen regulären Zyklus pro Sprint, d. H. Einmal in jedem Sprint durchgeführt.

Die Ereignisse geben einen Einblick, wie die Aufgaben in einer Scrum-Umgebung ausgeführt werden. Alle Scrum-Veranstaltungen bieten Möglichkeiten zur Verbesserung, Anpassung und Überprüfung.

Als nächstes folgt ein Tutorial zum Thema 'Fehlerprüfung'. Hierbei handelt es sich um eine formelle Besprechung, bei der alle Fehler des aktuellen Sprints besprochen und geprüft, d. H. Priorisiert werden.

PREV Tutorial | NÄCHSTES Tutorial

Literatur-Empfehlungen

• Scrum-Artefakte: Product Backlog, Sprint Backlog und Product Increments
• JIRA Scrum Board Tutorial: Scrum Handling mit Jira Zum Verwalten des Sprints
• Agile Scrum Online Quiz: Testen Sie Ihr Wissen über Agile Scrum
• So liefern Sie mithilfe des Agile Scrum-Prozesses in kurzer Zeit hochwertige Softwarefunktionen
• Fehler-Triaging in Scrum: Wie ist es in einem Scrum-Setup organisiert?
• Teilzeit freiberufliche Stellenangebot für Selenexperten
• Rollen und Verantwortlichkeiten des Scrum-Teams: Scrum-Master und Product Owner
• 10 beste Freizeituhr-Software für die Zeiterfassung von Mitarbeitern