Was ist Scrum Methodik: Alles, was sie wissen müssen

In diesem Blogbeitrag präsentiere ich einen langen Artikel, der zusammenfasst, was Scrum-Methodik ist. Hier finden Sie alles, was Sie über Scrum wissen müssen.

Viele meiner Leser fragen mich immer wieder "Was ist Scrum Methodik"? Ich werde Ihnen einen langen Artikel vorstellen, der das alles beschreibt. Dieser Artikel basiert auf dem Scrum Leitfaden.

Scrum ist definiert als ein Rahmenwerk, in dem die Leute  komplexe adaptive Probleme angehen können und gleichzeitig produktiv und kreativ in der Bereitstellung von Endprodukten mit höchster Wertschöpfung sind. Scrum verkörpert auch verschiedene Elemente, einschließlich leichtgewichtig und leicht zu verstehen zu sein. Es wird jedoch angemerkt, dass es schwierig ist, es zu meistern.

Ein genauer Blick auf die Scrum-Methodik

Wie bereits erwähnt, ist Scrum ein Rahmenwerk für Prozesse, das seit den frühen 1990er Jahren verwendet wird. Scrum wird für das Management komplexer Produktentwicklungen verwendet, und es werden verschiedene Prozesse und Techniken dabei verwendet, die dafür sorgen, dass dies erfolgt.

Wenn Sie Ihre Management- und Entwicklungspraktiken verbessern möchten, kann Scrum helfen, die relative Wirksamkeit Ihres Produktmanagements zu klären.

Das Rahmenwerk besteht aus Scrum Teams, die eine Reihe von Rollen ausführen, verschiedene Produkte und Ereignisse verantworten und eine Reihe von Regeln befolgen. Jeder Teil des Rahmens hat einen Zweck, der auf den Erfolg von Scrum hinwirkt.

Dieser Artikel erklärt alles, was Sie über Scrum wissen müssen, einschließlich der Regeln und Beziehungen, die damit verbunden sind. Darüber hinaus werden Taktiken diskutiert, die die verschiedenen Möglichkeiten aufzeigen, wie das Scrum Rahmenwerk verwendet werden kann.

Scrum verstehen: Scrum-Theorie

Um Scrum zu verstehen, ist es wichtig, es von seinen fundamentalen Grundlagen aus zu betrachten. Scrum basiert auf empirischer Prozesskontrolltheorie, die auch als Empirismus bekannt ist. Die Behauptung besteht darin, dass Wissen sowohl aus der Entscheidungsfindung als auch aus der Erfahrung bekannter Faktoren besteht.

Daher untersucht Scrum, wie die Vorhersagbarkeit optimiert und das Risiko mithilfe eines iterativen und inkrementellen Ansatzes kontrolliert werden kann. Dazu müssen drei Säulen für die Umsetzung vorhanden sein. Dies sind Transparenz, Inspektion und Anpassung.

Transparenz

Es gibt Teile dieses Prozesses, die für diejenigen sichtbar sein müssen, die für das Ergebnis verantwortlich sind. Dies erfordert Standarddefinitionen aller Aspekte, um ein gemeinsames Verständnis aller Beobachtungen zu gewährleisten. Betrachten Sie diese Beispiele:

• Alle Teilnehmer, die sich auf den Prozess beziehen, müssen eine gemeinsame Sprache verwenden
• Diejenigen, die die Arbeit durchführen, sowie diejenigen, die das Ergebnis abnehmen, müssen eine Standarddefinition von "done" haben.

Inspektion

Die Anwender von Scrum müssen Scrum Produkte und Fortschritte bei der Bewegung in Richtung eines Sprint-Ziels regelmäßig überprüfen. Dies stellt sicher, dass sie unerwünschte Zeitabweichungen erkennen. Es müssen hin und wieder Kontrollen durchgeführt werden, um die Arbeit nicht zu unterbrechen. Fachinspektoren stellen sicher, dass Inspektionen gut durchgeführt werden und sehr nützlich sind.

Adaptation

Nach einer Inspektion kann sich herausstellen, dass ein oder mehrere Aspekte innerhalb des Prozesses außerhalb akzeptabler Grenzen liegen. Dies bedeutet, dass das Endprodukt nicht akzeptabel sein würde und eine Anpassung  des Prozesses oder des verwendeten Materials vorgenommen werden muss. Je früher dies geschieht, desto besser, um die Möglichkeit weiterer Abweichungen zu verringern.

Scrum Team

Drei Mitglieder bilden das grundlegende Scrum-Team, das sind der Produkteigner, das Entwicklungsteam und der Scrum Master. Von diesen Teams wird erwartet, dass sie sich selbst organisieren und funktionsübergreifend arbeiten. Wenn sie sich selbst organisieren, können sie den besten Ansatz wählen, um die Arbeit zu erledigen, und müssen nicht von Leuten, die außerhalb des Teams sind, Anweisungen annehmen.

Als funktionsübergreifende Teams verfügen sie über alle Kompetenzen, um die anstehenden Aufgaben zu bewältigen, ohne sich auf andere außerhalb des Teams verlassen zu müssen. Das Team soll Flexibilität, Kreativität und Produktivität optimieren.

Scrum Teams liefern Produkte iterativ und inkrementell, um die Möglichkeiten für Feedback optimal zu nutzen. Inkrementelle Lieferungen von "Done"-Produkt stellen sicher, dass eine möglicherweise nutzbare Version des Arbeitsprodukts immer verfügbar ist.

Wenn Sie daran interessiert sind, ein großartiges Team auf den Weg zu bringen, werfen Sie einen Blick in diese beiden Artikel: "Wie man ein großartiges agiles Team ins Laufen bringt" und "Wie man ein Team zum Kick-Off-Meeting bringt".

Der Product Owner

Wenn es darum geht, den Wert des Produkts und die Arbeitsleistung des Entwicklungsteams zu maximieren, ist dafür der Produkteigner verantwortlich. Dies kann basierend auf den Scrum Teams und den Personen innerhalb des Teams variieren. Der Product Owner (PO) trägt die alleinige Verantwortung für die Verwaltung des Produktbestands. Diese Verwaltung beinhaltet:

• Produktbestand eindeutig benennen
• Artikel im Produktbestand verteilen, um die Missionen und Ziele zu erreichen
• Optimierung der Wertschöpfung der Arbeitsleistung, die das Entwicklungsteam leistet
• Sicherstellen, dass der Produktbestand für alle sichtbar, transparent und klar ist.

Dies verrät, woran das Scrum Team als nächstes arbeiten soll und stellt sicher, dass das Entwicklungsteam die Artikel im Produktbestand vollständig auf dem erforderlichen Niveau versteht. Obwohl die POs diese Arbeit an ihr Entwicklungsteam delegieren können, sind sie für die Ergebnisse verantwortlich.

Der PO ist ein Individuum und kein Ausschuss.

Wenn ein Ausschuss vorhanden ist, könnte der seine Wünsche in den Produktbestand eingeben. Wer daran etwas ändern möchte, muss sich an den PO wenden.Um sicherzustellen, dass der PO erfolgreich ist, muss jeder in der Organisation seine Entscheidungen respektieren, die im Inhalt und in den Aufträgen des Produktbestands sichtbar sind.

Es ist niemand in der Lage, dem Entwicklungsteam zu sagen, dass es mit alternativen Anforderungen arbeiten soll, und das Entwicklungsteam ist auch in der Reaktion auf Anweisungen von Anderen beschränkt.

Das Entwicklungsteam

Dies ist ein Team, das sich aus Fachleuten zusammensetzt, die daran arbeiten, am Ende jeden Sprints ein potentiell freigebbares Teilstück eines "Done"-Produktes zu liefern. Nur die Mitglieder dieses Teams können das Inkrement erstellen.

Die Organisation stellt sicher, dass das Entwicklungsteam befugt ist, seine Arbeit selbst zu organisieren und zu verwalten. Die Synergie, die dadurch entsteht, wird die Effizienz und Effektivität des Entwicklungsteams optimieren. Diese Teams haben folgende Eigenschaften:

•   Sie sind selbstorganisierend. Sie erhalten keine Anweisungen oder Ratschläge von Anderen, wie man Produktbestand in Teilschritte mit potentiell freigebbarer Funktionalität umsetzt.

•   Sie sind funktionsübergreifend und verfügen über alle erforderlichen Fähigkeiten, um ein Produktinkrement zu erstellen.

•   Scrum kennt keine Titel im Entwicklungsteam. Jeder ist ein Entwickler, egal welche Arbeit er gerade ausführt. Dies gilt ohne Ausnahme.

•   Das Scrum stellt fest, dass es innerhalb des Entwicklungsteams keine Unterteams gibt. Dies ist auch dann zu beachten, wenn mehrere Domänen behandelt werden müssen, z. B. Unternehmensanalysen oder Tests. Dies gilt ohne Ausnahme.

•   Jedes Mitglied des Entwicklungsteams kann eine spezielle Fähigkeit oder einen speziellen Bereich haben, wenn es aber um die Rechenschaftspflicht geht, wird das Team als Ganzes gesehen.

Das Entwicklungsteam besteht aus mehreren Personen, wobei normalerweise drei die optimale Anzahl ist. Dies stellt sicher, dass sie flink bleiben und trotzdem groß genug sind, um alle Arbeiten zu fertigzustellen, die innerhalb eines Sprints erledigt werden müssen.

Wenn das Team weniger als drei Mitglieder hat, wird die Interaktion reduziert, was bedeutet, dass die Ergebnisse kleinere Produktivitätsgewinne haben. Außerdem können die kleinen Entwicklungsteams während des Sprints Einschränkungen in ihren Fähigkeiten haben, was bedeutet, dass sie möglicherweise kein potenziell freisetzbares Teilstück liefern können.

Große Teams wie solche mit mehr als neun Mitgliedern brauchen viel mehr Koordination. Sie erzeugen letztendlich zu viel Komplexität um einen empirischen Prozess zu verwalten. Beim Abzählen des Entwicklungsteams werden der PO und der Scrum Master nicht mitgezählt, es sei denn, sie führen auch Arbeiten im Sprint Produktbestand aus.

Der Scrum Master

Der Scrum Master hat die Verantwortung, sicherzustellen, dass Scrum verstanden und umgesetzt wird. Er arbeitet mit dem Scrum-Team zusammen, so dass sich diese an die Scrum-Theorie, -Praktiken und -Regeln halten können.

Der Scrum Master ist im Wesentlichen der Diener/ die Leitung für das Scrum Team. Wenn Sie in der Situation sind, dass Sie Scrum Master für zwei Teams sind, werfen Sie einen Blick in: "Ihre brennendsten Fragen zur Leitung von 2 Teams als Scrum Master ".Der Scrum Master hilft Personen, die nicht im Scrum Team sind, zu verstehen, welche ihrer Interaktionen mit dem Scrum Team hilfreich sind und welche nicht.

Die Leistungen des Scrum Masters verstehen

Die Leistungen des Scrum Masters umfassen drei Gruppen:

Scrum Master Service für den PO

Dies geschieht auf verschiedene Arten, einschließlich:

• Techniken für ein effektives Produktbestandmanagement finden
• Unterstützung des Scrum-Teams, um den Produktbestand klar und genau zu verstehen
• Verständnis der Produktplanung in einem empirischen Umfeld
• Sicherstellen, dass der PO sich bewusst ist, wie der Produktbestand bestmöglich zu gestalten ist
• Verständnis für und Ausübung von Agilität
• Scrum-Veranstaltungen nach Bedarf oder Wunsch mitgestalten

Scrum Master Service für das Entwicklungsteam

Hier wird der Scrum Master dem Entwicklungsteam auf folgende Weise helfen:

• Coaching des Entwicklungsteams in Selbstorganisation und funktionsübergreifenden Aktionen
• Unterstützung des Entwicklungsteams bei der Erstellung hochwertiger Produkte
• Hindernisse für den Fortschritt des Entwicklungsteams beseitigen
• Scrum-Veranstaltungen nach Bedarf oder Wunsch mitgestalten
• Coaching des Entwicklungsteams in organisatorischen Umgebungen, in denen Scrum nicht vollständig angenommen oder verstanden wurde

Scrum Master Service für die Organisation

Scrum Master können der Organisation auf verschiedene Arten dienen

•       Führung und Coaching der Organisation bei der Adaption von Scrum

•       Planung der Scrum-Implementierung innerhalb der Organisation

•       Hilfestellung für Mitarbeiter und Interessenvertreter, Scrum und die empirische Produktentwicklung zu verstehen

•       Veränderungen bewirken, die zur Produktivitätssteigerung der Scrum-Teams führen

•       Zusammenarbeit mit anderen Scrum Mastern, um die Effektivität der Scrum-Aktivierung innerhalb der Organisation zu erhöhen

Scrum Werte

Es gibt mehrere Werte, die das Scrum-Team verkörpern und leben muss. Dies sind Mut, Engagement, Offenheit, Respekt und Fokus. Diese Werte sind die Grundlage dafür, die Scrum Säulen zum Leben zu erwecken und Vertrauen bei allen Beteiligten aufzubauen.

Die Mitglieder des Scrum Teams erfahren und erforschen die Werte, während sie mit Scrum Veranstaltungen, Rollen und Aufgaben arbeiten. Damit Scrum erfolgreich ist, müssen die Teammitglieder diese fünf Werte beherrschen.

Das machen Sie so:

• Sie haben den Mut, das Richtige zu tun und an schwierigen Problemen zu arbeiten
• Sie verpflichten sich, die Ziele des Teams zu erreichen
• Die Interessenvertreter und das Team einigen sich darauf, offen über die Arbeit und die Herausforderungen bei der Durchführung der Arbeit zu sprechen
• Sie respektieren einander und vertrauen darauf, dass sie unabhängig und fähig sind, die Ziele zu erreichen
• Sie konzentrieren sich auf die Arbeit des Sprints und die Ziele des Teams

Scrum Veranstaltungen: Inspektions- und Anpassungsveranstaltungen

Es gibt formal vorgeschriebene Ereignisse, die im Scrum verwendet werden. Diese regeln und minimieren oft die Notwendigkeit von Meetings, die nicht für das Scrum entworfen wurden. Alle diese Veranstaltungen sind zeitlich begrenzt, was bedeutet, dass sie alle eine maximale Dauer haben.

In dem Moment, in dem ein Ereignis wie der Sprint beginnt, gibt es eine feste Dauer, die nicht geändert werden kann. Sobald der Zweck der Veranstaltung erfüllt ist, können alle anderen verbleibenden Ereignisse beendet werden. Dies stellt sicher, dass nur minimale Zeit während des Prozesses verschwendet wird.

Jede Veranstaltung bietet die Möglichkeit, etwas zu inspizieren oder anzupassen, und wurde so konzipiert, dass sie eine kritische Transparenz ermöglicht. Es gibt vier formelle Ereignisse, die Scrum ebenfalls vorschreibt. Diese sind:

• Sprintplanung
• Täglicher Scrum
• Sprint Review
• Sprint Retrospektive 

Den Sprint verstehen

Der Kern des Scrum ist ein Sprint. Dies kann als ein Zeitrahmen von einem Monat oder weniger definiert werden, wenn ein "fertig" Produkt, ein verwendbarer und potentiell freigebbarer Produktschritt, erstellt wird. In der Regel haben sie während der gesamten Entwicklungszeit konsistente Laufzeiten. Sprints sollten während der gesamten Entwicklungszeit konstant sein. Ein neuer Sprint beginnt erst, wenn ein vorheriger Sprint abgeschlossen wurde.

Sprints enthalten und bestehen aus Sprint Planung, täglichen Scrums, Sprint Rückschau, Sprint Retrospektive und der Entwicklungsarbeit.

Während der Sprint läuft, sollten keine Änderungen vorgenommen werden, die sich auf das Sprint Ziel auswirken könnten, die Qualitätsziele werden nicht verringert, und der Umfang kann geklärt und neu verhandelt werden, je nachdem, ob der PO und das Entwicklungsteam mehr Neues erfahren haben.

Sicherheitshalber sollte man jeden Sprint als ein Projekt, das etwas erreichen soll, mit Dauer eines Monats, betrachten.

Aus diesem Grund ist im Sprint klar definiert, was zu bauen ist, welches Design, und es gibt einen flexiblen Plan für den Einbau, die Arbeit und das Endprodukt. Sollte der Zeithorizont eines Sprints mehr als ein Monat betragen, dann könnte sich die Definition dessen, was gebaut wird, ändern, das Risiko steigt, ebenso wie die Gesamtkomplexität.

Sprints sind wichtig, da sie sicherstellen, dass die Arbeit vorhersehbar ist und überprüft und angepasst werden kann, wenn man sich dem Sprint Ziel nähert. Sie begrenzen das Risiko, insbesondere in Bezug auf die Kosten.

Es ist möglich, einen Sprint abzubrechen, bevor die Sprint Zeit zu Ende geht. Die einzige Person, die dazu befugt ist, ist der PO. Diese Entscheidung kann von anderen beeinflusst werden, einschließlich der Interessenvertreter, des Entwicklungsteams oder des Scrum Masters. Eine Stornierung kann in Kraft treten, wenn das Sprint Ziel obsolet wird.

Veralterung kann durch eine Veränderung der Richtung, der  Markt- oder Technologiegegebenheiten verursacht werden. Wenn der Sprint keinen Sinn mehr macht, sollte er abgebrochen werden. Sie werden jedoch feststellen, dass ein Abbruch selten passiert, da Sprints eine so kurze Dauer haben.

Es gibt Schritte, die stattfinden müssen, nachdem der Sprint abgebrochen wurde. Die abgeschlossenen und als "done" bezeichneten Produktbestandsartikel werden zuerst überprüft. Sollten einige der Arbeiten aus dem Sprint potenziell freigebbar sein, wird dies vom PO akzeptiert. Die unvollständigen Elemente, die im Produktbestand sind, werden erneut bewertet und an den Produktbestand zurückgegeben.

Da diese Art von Arbeit schnell an Wert verlieren kann, muss sie häufig neu durchgeführt werden.

Von Stornierungen wird abgeraten, da sie Ressourcen verbrauchen. Dies liegt daran, dass sich alle, die am Sprint beteiligt sind, neu gruppieren und sich dann in einem anderen Sprint Planungsprozess befinden, um einen weiteren Sprint zu starten. Sie verursachen beim Scrum Team ein gewisses Trauma und werden deswegen vermieden.

Sprint Planung

Alle Arbeiten, die im Sprint ausgeführt werden sollen, werden bei der Sprint Planung eingeplant. Der Plan entsteht durch kollaboratives Arbeiten und bringt das gesamte Scrum Team zusammen. Die Sprint Planung ist für einen Sprint, der einen  Monat dauert, auf maximal acht Stunden begrenzt. Hier finden Sie einen Vorschlag, wie Sie eine effektive Sprint Planung durchführen können.

Wenn der Sprint kürzer ist, wird diese Veranstaltung auch eher kürzer sein. Es liegt am Scrum Master, sicherzustellen, dass die Veranstaltung stattfindet und die Teilnehmer den Grund für das Veranstaltung verstehen. Der Scrum Master wird dann das Team anleiten, innerhalb der definierten Zeitbox zu bleiben.

Planung ist die Antwort auf die Frage, was im Inkrement des kommenden Sprints geliefert werden kann und wie die Arbeit, die notwendig ist, um den Teilschritt abzuliefern, erreicht wird.

Was kann durch den bevorstehenden Sprint geliefert werden?

Während des Sprint Planungszeitraums arbeitet das Entwicklungsteam an der Vorhersage der Funktionalität, die während des Sprints entwickelt werden soll. Der Product Owner wird das Ziel besprechen, das der Sprint anstrebt, darüber hinaus auch, welche Produktbestands-elemente zur Erreichung des Sprint Ziels beitragen. Das gesamte Scrum Team arbeitet zusammen, um die Arbeitsaufgaben des Sprints zu verstehen.

Dieses Meeting hat einen primären Inhalt, und zwar den Produktbestand, den neuesten Produktteilschritt, die voraussichtliche Kapazität des Entwicklungsteams während des Sprints und die vorherige Leistung des Entwicklungsteams.

Das Entwicklungsteam wählt aus, wie viele Artikel aus dem Produktbestand für den Sprint genommen werden. Es ist das Entwicklungsteam, das Informationen darüber bereitstellt, was sie über die Sprint Erwartungen hinaus erreichen können.

Nach einer Prognose über die Produktbestandsteile wird das Entwicklungsteam den Sprint entwickeln, während das Scrum Team das Sprint Ziel erstellen wird. Das Sprint Ziel ist das Ziel, das im Sprint erreicht wird, wenn das Produktbestand implementiert wurde. Es bietet dem Entwicklungsteam Orientierung darüber, warum das Increment aufgebaut wird.

Wenn Sie sich für das Thema interessieren, Chris hat vor einiger Zeit einen Blogpost geschrieben: "Vier Gründe, warum agile User Stories nicht fertig werden", werfen Sie einen Blick darauf.

Wie wird die Arbeit erledigt?

Sobald das Sprint Ziel festgelegt wurde und die Elemente des Produktbestands für den Sprint ausgewählt wurden, entscheidet das Entwicklungsteam, wie die Funktionalität während des Sprints in einen "Done" Produktteilschritt integriert wird. Die Produktbestandsartikel, die für diesen Sprint ausgewählt werden, werden zusammen mit dem Plan, wie sie zu liefern sind, als Sprint Produktbestand bezeichnet.

Das Entwicklungsteam wird ein System entwickeln, um den Produktbestand in ein funktionierendes Produkt Inkrement zu konvertieren. Die Arbeit kann in Bezug auf Aufwand und Größe des Jobs variieren. Während der Sprintplanung wird das Entwicklungsteam prognostizieren, was im bevorstehenden Sprint erreicht werden kann.

Am Ende des Meetings werden die Arbeiten, die für die ersten Tage des Sprints geplant waren und vom Entwicklungsteam durchgeführt werden sollen, in tägliche (oder kleinere) Einheiten zerlegt.

Dann findet eine Selbstorganisation statt, um die Arbeit im Sprint Produktbestand sowohl während der Sprint Planung, als auch während der Dauer des Sprints zu erledigen.

Der Product Owner hat die Aufgabe, zur Klärung der ausgewählten Produktbestandsartikel beizutragen und dann gegebenenfalls Kompromisse einzugehen. Sollte das Entwicklungsteam entscheiden, dass die Arbeit zu viel oder zu wenig ist, kann sie basierend auf dem Produktbestandsinhalt neu ausgehandelt werden.

Dies geschieht zusammen mit dem Product Owner . Es steht dem Entwicklungsteam auch frei, Andere zur Teilnahme einzuladen, um Ratschläge zu Domain oder technischen Fragen einzuholen.

Am Ende der Sprint Planung sollte das Entwicklungsteam die Möglichkeit haben, dem PO und dem Scrum Master zu erklären, wie die Arbeit als selbstorganisierendes Team zur Erfüllung des Sprint Ziels durchgeführt wird.

Sprint Ziel

Dies ist ein Ziel, das für den Sprint festgelegt wurde und leicht erfüllt werden kann, sobald der Produktbestand implementiert wurde. Es bietet dem Entwicklungsteam eine Orientierungshilfe für die Ursache, warum der Teilschritt erstellt wird. Während des Sprint Planungs Meeting wird das Sprint Ziel erstellt.

Es stellt sicher, dass das Entwicklungsteam ein gewisses Ausmaß an Flexibilität bezüglich der im Sprint implementierten Funktionalität hat. Das Sprint Ziel wird über die Produktbestandsteile bereitgestellt und stellt sicher, dass das Entwicklungsteam zusammenarbeiten kann, anstatt in separate Initiativen abzugleiten.

Das Entwicklungsteam arbeitet stets mit dem Sprint Ziel und dies beeinflusst ihre Funktionalität und ihren Einsatz von Technologie. Wenn sich die Erwartungen ändern, werden das Entwicklungsteam und der Product Owner die Zusammenarbeit fördern, um den Umfang des Sprint Produktbestands im Sprint zu verhandeln.

Täglicher Scrum

Jeden Tag nimmt sich das Entwicklungsteam 15 Minuten Zeit, um seine Aktivitäten zu synchronisieren und einen Plan für die nächsten 24 Stunden zu entwickeln. Dies wird als täglicher Scrum bezeichnet. Er beinhaltet eine Überprüfung der Arbeit, die seit dem letzten täglichen Scrum geleistet wurde, und einem Ausblick auf auf die Arbeit, die vor dem Nächsten getan werden muss.

Es ist wichtig, dass Zeit und Ort des täglichen Scrum jeden Tag gleich bleiben, da dies Komplexität reduziert. Im Meeting wird das Entwicklungsteam folgendes untersuchen:

• Was am Vortag getan wurde, das geholfen hat, das Sprint Ziel zu erreichen
• Was wurde heute getan, um zu helfen, das Sprint-Ziel zu erreichen?
• Welche Hindernisse behindern möglicherweise ihre Fähigkeit, das Sprint Ziel zu erreichen?

Das bedeutet, dass der tägliche Scrum wie ein Fährtenleser für die Fortschrittskontrolle des Sprint Ziels ist. Er stellt sicher, dass die Arbeit auf dem richtigen Weg ist, auf dem Sprint Produktbestand basiert und es so viel einfacher macht, das Ziel zu erreichen. Das Entwicklungsteam wird während des täglichen Scrum herausgefordert, als selbstorganisierendes Team durch ausführliche Diskussionen zusammenzuarbeiten, in denen sie den Rest der Sprint Arbeit anpassen oder wiederholen müssen.

Es ist der Scrum Master, der sicherstellt, dass dieses Treffen jeden Tag stattfindet, obwohl es vom Entwicklungsteam durchgeführt wird. Der Scrum Masters stellt sicher, dass  die Dauer unter 15 Minuten bleibt und die Regeln für die Teilnahme eingehalten werden.

Die Vorteile des täglichen Scrum sind vielfältig, darunter die Verbesserung der Kommunikation, die Reduzierung des Bedarfs an anderen Meetings, das Identifizieren von Entwicklungshindernissen, die schnelle Entscheidungsfindung und die Erhöhung des Gesamtwissens des Entwicklungsteams. Vor einiger Zeit schrieb ich einen weiteren Blog über "How to run an effective DailyScrum", schauen Sie gerne rein.

Sprint Rückschau

Die Sprint Rückschau wird ausgeführt, sobald der Sprint durchgeführt wurde. Sie ist dafür vorgesehen, das Inkrement zu überprüfen und den Produktbestand anzupassen, wenn es notwendig ist. Wenn die Sprint Rückschau stattfindet, beurteilen das Scrum Team und die Interessenvertreter, was während des Sprints getan wurde.

Das Ergebnis ihrer Diskussion kann zu Änderungen im Produktbestand sowie zu einer Überprüfung dessen führen, was zur Wertsteigerung optimiert werden kann.

Die Überprüfung dient zum Austausch von Informationen und ist kein Status Meeting. Sie dient lediglich dazu, Feedback zu erhalten und sicherzustellen, dass es eine Zusammenarbeit gibt. Wenn der Sprint einen Monat gedauert hat, dann wird es über einen Zeitraum von vier Stunden stattfinden. Wenn der Sprint kürzer war, wird das Treffen auch kürzer.

Er enthält die folgenden Elemente:

• Teilnahme des Scrum Teams und der Interessenvertreter auf Einladung des POs
• Der PO erklärt die Produktbestandsartikel, die "fertig" und nicht "fertig" sind.
• Das Entwicklungsteam erklärt, was während des Sprints funktioniert hat und was nicht funktioniert hat und wie Probleme gelöst wurde
• Das Entwicklungsteam erklärt, was "fertig" ist und gibt Antworten zum Inkrement
• Der PO bespricht den Stand des Produktbestands und definiert mögliche Fertigstellungstermine
• Die gesamte Gruppe arbeitet bei den nächsten Schritten zusammen, damit die Sprint Rückschau wertvolle Informationen für die zukünftige Sprint Planung liefert
• Überprüfung der Marktbedingungen oder der möglichen Verwendung des Produkts, Änderungen, und was die wertvollste Sache ist, die als nächstes gemacht werden soll
• Überprüfung des Zeitplans, des Budgets, der Funktionen und des Markts für die Veröffentlichung des Produkts

Nach dem Sprint Review wird der Produktbestand oft überarbeitet, und die möglichen Produktbestandteile für den nächsten Sprint werden definiert. Er kann auch in Gesamtheit angepasst werden, um neue Möglichkeiten zu finden.

Sprint Retrospektive

Dies ist die Chance für das Scrum Team, eine Inspektion dessen, was gemacht wurde, durchzuführen und einen Plan für Verbesserungen für den nächsten Sprint zu entwickeln. Dies geschieht, sobald die Sprint Überprüfung abgeschlossen ist, bevor die Sprint Planung erneut beginnt.

Es handelt sich um ein Zeitfenster, das über drei Stunden für einmonatige Sprints stattfindet. Kürzere Sprints führen zu kürzeren Meetings. Der Scrum Master wird dafür sorgen, dass es stattfindet und dass die Teilnehmer seinen Zweck kennen.

Der Scrum Master wird als Peer-Teammitglied Informationen zur Verantwortlichkeit im Scrum-Prozess weitergeben. Der Zweck dieses Treffens ist:

• Den letzten Sprint zu überprüfen
• Identifizieren und ordnen der wichtigen Elemente, die funktionierten und was verbessert werden mus
• Entwickeln eines Plans, um das Scrum Team und seine Arbeitsweise zu verbessern

Der Scrum Master wird diesen Weg nutzen, um das Scrum Team zu ermutigen, sich innerhalb seines Prozessrahmens, Entwicklungsprozesses und seiner Vorgehensweisen zu verbessern. Dies wird sicherstellen, dass der nächste Sprint effektiver und angenehmer ist. Pläne werden festgelegt, um die Produktqualität durch eine passende Definition von "fertig" zu verbessern.

Sobald die Sprint Retrospektive abgeschlossen ist, wird das Scrum Team ermittelt haben, was für den nächsten Sprint verbessert werden kann. Diese werden angepasst und dann vom Scrum Team selbst überprüft. Es ist die Sprint Retrospektive, die eine formelle Gelegenheit bietet, sich auf Inspektion und Anpassung zu konzentrieren.

Wenn Sie an diesem Thema interessiert sind, können Sie in meinem anderen Artikel: "The Agile Retrospectives Guide That Will Make You A Fantastic Facilitator" weiterlesen. Mein Freund Marc Loeffler hat einen Artikel geschrieben über: "The most 5 asked questions about Agile Retrospectives".

Und natürlich, wenn Sie nach neuen Ideen für Ihre Sprint Retrospektive suchen, werfen Sie einen Blick in: "Agile Retrospectives Ideas".

Scrum Artikel

Diese stellen die Arbeit oder den Wert dar, um Transparenz sowie Möglichkeiten zur Überprüfung und Anpassung zu schaffen. Sie sind so definiert, dass sie speziell darauf ausgelegt sind, die Transparenz der Schlüsselinformationen zu maximieren, so dass alle Beteiligten das gleiche Verständnis für den Artikel haben.

Produktbestand

Damit wird eine geordnete Liste aller Dinge, die für das Produkt benötigt werden, bezeichnet. Er enthält alle Anforderungen für Änderungen, die an einem Produkt vorgenommen werden müssen, der PO ist dafür verantwortlich.

Dies ist eine laufende Arbeit, die nie wirklich eine finale Version hat. Sie legt die Anforderungen fest und entwickelt sich mit der Entwicklung des Produkts weiter. Sie ändert sich basierend darauf, was das Produkt angemessener, nützlicher und wettbewerbsfähiger macht und existiert, so lange es ein Produkt gibt.

Sie enthält eine Liste aller Funktionen, Anforderungen, Funktionen, Verbesserungen und Korrekturen, die die Änderungen enthalten, die in Zukunft an einem Produkt vorgenommen werden müssen. Die Artikel innerhalb des Produktbestands haben eine Beschreibung, Bestellung, Kostenschätzung und Wert.

Je mehr das Produkt verwendet wird und je mehr Wert es bekommt, desto mehr Feedback kann vom Markt erwartet werden. Dies wird zum Wachstum des Produktbestands führen, wenn sich die Anforderungen weiterentwickeln. Es kann sich auch ändern durch unternehmerische Anforderungen, den Marktbedingungen und der Technologie.

Bei mehreren Scrum Teams muss möglicherweise an einem Produkt zusammengearbeitet werden. In diesem Fall wird nur ein Produktbestand verwendet, um das Produkt zu beschreiben. Um den Produktbestand zu verfeinern, können Detailangaben, Schätzungen und die Reihenfolge der Artikel geändert werden.

Dies geschieht in Zusammenarbeit mit dem PO und dem Entwicklungsteam. Während es verfeinert wird, werden auch die darin enthaltenen Elemente überprüft und überarbeitet. Es ist das Scrum Team, das entscheidet, wie die Verfeinerung durchgeführt wird, damit nicht mehr als 10% Kapazität vom Entwicklungsteam abgezogen wird. Der PO behält sich das Recht vor, den Produktbestand jederzeit zu aktualisieren.

Es gibt ranghöhere und rangniedrigere Produktbestandteile, wobei die höher gereihten detaillierter und klarer sind. Es sind die höher gereihten, die vernünftigerweise vom Entwicklungsteam "done" gemacht werden können, und sie werden dann in der Sprint Planung als "Bereit" zur Auswahl angesehen.

Das Entwicklungsteam ist für alle Schätzungen verantwortlich, da sie die Personen sind, die die Arbeit ausführen.

Überwachung des Fortschritts in Richtung eines Ziels

Es ist zu jeder Zeit möglich, den Arbeitsaufwand zu berechnen, der benötigt wird, um ein Ziel zu erreichen. Während der Sprint Retrospektive wird der Product Owner feststellen, wie viel Arbeit noch zu leisten ist.

Es wird ein Vergleich mit der Arbeit gemacht, die von vorherigen Sprint Retrospektiven übriggeblieben ist und der Fortschritt, der erforderlich ist, um den aktuellen Sprint in der festgelegten Zeit abzuschließen. Diese Informationen werden dann an alle beteiligten Interessenvertreter weitergegeben.

Zur Vorhersage des Fortschritts werden kumulative Abläufe, Burndowns und Burnups verwendet. Wo ein komplexes Umfeld herrscht, kann das Endergebnis unbekannt sein, so dass nur das, was in der Vergangenheit passiert ist, für eine vorausschauende Entscheidungsfindung herangezogen werden kann.

Sprint Produktbestand

Die Produktbestandteile, die für den Sprint ausgewählt werden, werden als Sprint Produktbestand bezeichnet. Sie enthalten auch den Plan, wie das Produkt Inkrement zu liefern und das Sprint Ziel zu realisieren ist.

Grundsätzlich ist der Sprint Produktbestand eine Prognose des Entwicklungsteams, das untersucht, wie funktional jedes Inkrement sein wird, sowie die Arbeit, die erforderlich ist, um die Funktionalität für ein "done" Inkrement zu liefern.

Der Sprint Produktbestand stellt sicher, dass alle Arbeiten des Entwicklungsteams sichtbar und identifizierbar sind, um das Sprint Ziel zu erreichen. Der Sprint Produktbestand ist im Wesentlichen ein Plan, der die im laufenden täglichen Scrum erforderlichen Detailinformationen für Änderungen im Fortschritt enthält.

Das Entwicklungsteam kann den Spirit Produktbestand während des gesamten Sprints modifizieren, was dann während des Sprints auftaucht, während das Entwicklungsteam den Plan durcharbeitet. Dies liegt daran, dass mehr über die Arbeit gelernt wird, die notwendig ist, um das Sprint Ziel zu erreichen.

Wenn neue Arbeiten erforderlich sind, werden sie vom Entwicklungsteam dem Sprint Produktbestand hinzugefügt. Während der Fertigstellung wird die geschätzte Restarbeit aktualisiert. Währenddessen werden alle Elemente des Plans, die nicht notwendig sind, entfernt.

Nur das Entwicklungsteam kann den Sprint Produktbestand im Laufe eines Sprints ändern. Der Sprint Produktbestand ist wie ein sichtbarer Bauplan für das Entwicklungsteam und gehört ausschließlich dem Entwicklungsteam.

Überwachen des Sprint Fortschritts

Während des Sprints kann der Sprint Produktbestand jederzeit zusammengefasst werden. Es ist die Aufgabe des Entwicklungsteams, die Gesamtarbeit für jedes tägliche Scrum zu verfolgen, um die Möglichkeit zu testen, das Sprint Ziel zu erreichen. Rückverfolgung ermöglicht es dem Entwicklungsteam, den Fortschritt zu steuern.

Inkrement

Die gesamte Arbeit innerhalb des Sprint Produktbestands kann zu diesem Zeitpunkt zusammengefasst werden. Das Inkrement ist die Summe dieser Werte sowie der Wert aller anderen Inkremente aus früheren Sprints.

Das letzte Inkrement am Ende des Sprints sollte "done" sein, was bedeutet, dass es sich in einem operativen Zustand befindet und die vom Scrum Team festgelegte Definition erfüllt.

Der nutzbare Zustand ist notwendig, unabhängig davon, ob derProduct Owner sich dafür entscheidet, ihn zu veröffentlichen oder nicht.

Artikeltransparenz

Damit Scrum das ist, was es ist, ist Transparenz essentiell. Dies ist die Grundlage für Entscheidungen, die sowohl zur Wertoptimierung als auch zur Risikokontrolle getroffen werden. Das Ausmaß der Transparenz bestimmt, ob Entscheidungen fundiert sind oder nicht.

Wenn die Artikel nicht vollständig transparent sind, sind die Entscheidungen fehlerhaft und ihr Wert wird sinken. Darüber hinaus wird das Risiko steigen.

Der Scrum Master muss mit allen involvierten Parteien einschließlich dem PO und dem Entwicklungsteam, zusammenarbeiten, um sicherzustellen, dass die Artikel vollständig transparent sind. Für den Fall, dass es unvollständige Transparenz gibt, gibt es Praktiken, um das zu lösen.

Der Scrum Master muss allen helfen, die am besten geeigneten Praktiken dort anzuwenden, wo die Transparenz nicht vollständig ist.

Unvollständige Transparenz kann vom Scrum Master erkannt werden, wenn die Artikel untersucht, Muster erkannt und alle Informationen sorgfältig beobachtet werden.Daraus können Unterschiede zwischen den tatsächlichen und erwarteten Ergebnissen abgeleitet werden.

Der Scrum Master muss sowohl mit dem Scrum Team als auch mit der Organisation zusammenarbeiten, um die Transparenz der Artikel zu erhöhen. Dies geschieht durch Lernen, Überzeugen und Veränderung und erfordert einen definierten Weg, um es richtig zu machen.

Die Definition von “done”

Der Begriff "done" ist in diesem Text mehrmals aufgetaucht. Wenn ein Produktbestand oder ein Inkrement als "done" bezeichnet wird, müssen alle Beteiligten die Bedeutung verstehen.

Er bezieht sich direkt auf die abgeschlossene Arbeit und sorgt für Transparenz. Für das Scrum Team bedeutet "done", dass die geleistete Arbeit am Produkt Inkrement abgeschlossen ist. Vor einiger Zeit habe ich ein Beispiel für eine "Definition of Done Checklist" geschrieben.

Diese Definition bietet dem Entwicklungsteam eine Orientierungshilfe für die Anzahl der Produktbestandteile, die während des Sprint Planungsprozesses ausgewählt werden sollten. Der Grund dafür, dass jeder Sprint existiert, ist die Bereitstellung von Inkrementen potenziell freigebbarer Funktionen, die in die Definition von "done" des Scrum Teams passen.

Mit jedem Sprint sollte das Entwicklungsteam einen Teilschritt für die Produktfunktionalität liefern. Ist es nutzbar, kann der PO sich entschließen, es sofort freizugeben. Für den Fall, dass es ein Teil der Konventionen, Standards oder Richtlinien der Entwicklungsorganisation ist, eine Definition von "done" für ein Inkrement festzulegen, müssen alle Scrum Teams das als Mindestanforderung sehen.

Für den Fall, dass die Definition von "done" keine Vereinbarung der Entwicklungsorganisation ist, hat das Entwicklungsteam des Scrum Teams die Aufgabe, eine dem Produkt entsprechende Definition von "done" zu erstellen. Wenn zahlreiche Scrum Teams an der Produktfreigabe arbeiten, müssen die Entwicklungsteams ein für alle gemeinsam geltendes "done" definieren.

Jedes Inkrement addiert sich zu allen vorherigen Inkrementen und wird gründlich getestet. Dies stellt sicher, dass sie alle zusammenarbeiten.

Wenn Scrum Teams reifer werden, werden ihre Definitionen von "done" auch durch klarere Kriterien erweitert. Hier präsentiere ich Ihnen einige Vorschläge, wie Sie mit diesem Ansatz beginnen können. Jedes System und Produkt benötigt eine Definition von "done", die der Standard ist, der auf die Arbeit angewendet wird.

Ich denke, das ist weitreichende Zusammenfassung von "Was ist  Scrum Methodik". Hinterlassen Sie mir gerne Ihre Kommentare unten.

Hat Ihnen dieser Artikel gefallen?

Wir ermöglichen Führungskräften, durch die Anpassung ihres projektzentrierten Unternehmens zu einem produktorientierten Unternehmen, hoch geschätzt und anerkannt zu werden.

Die Gesellschaft hat sich verändert und Führungskräfte benötigen Unterstützung, um ihre Unternehmen an das digitale Zeitalter anzupassen. Aus diesem Grund wurde die ADAPT Methodology® geschaffen!

Wenn Sie wissen möchten, ob Ihr Unternehmen projektzentriert oder produktgeführt ist, machen Sie einfach unseren „Project To Product Scorecard“.

Wenn Sie wissen möchten, wie wir Ihnen bei Ihrem Transformationsbeginn helfen können, werfen Sie einen Blick auf unser: „Projekt zu Produkt Schulung“.

Wenn Sie an einer Transformation in Ihrem Unternehmen interessiert sind, sehen Sie sich bitte unser Angebot an: „Projekt zu Produkt Beratung“.