Document ID: /fineweb-2-swissfilter-quality_10-filterrobots/filtered/03617.jsonl.gz/565

Scrum ist ein einfaches Framework zur Lösung komplexer Probleme. Komplexe Probleme sind per Definition nicht mit einem (ausgefeilten) Plan lösbar. Gerade bei Produkt- und Software-Entwicklungen handelt es sich um komplexe Problemstellungen.
Das Framework umfasst drei Rollen, drei Artefakte und fünf Events, insgesamt also elf Bestandteile und ist somit ein sehr schlankesFramework. Scrum baut auf dem Agile Manifesto und den entsprechenden Prinzipien auf.
Das Framework lässt sich wie folgt veranschaulichen:
Diese Werte sind wichtig, da sie letztendlich das gegenseitige Vertrauen im Scrum-Team fördern. Vertrauen ist entscheidend für den Erfolg eines Teams.
Die Aufgabe des Scrum Masters ist es, das Befolgen der Scrum-Regeln zu fördern. Dabei arbeitet der Scrum Master eng mit dem Team und der Organisation zusammen. Insbesondere ist er/sie auch für das Entfernen von Hindernissen (Impediments) des Teams in der Organisation zuständig.
Diese Rolle ist sehr vielfältig und wird in den meisten Unternehmen unterschätzt. Das „Agile Coaching Institute“ zeigt verschiedene Haltungen auf, die ein Scrum Master einnehmen kann:
Die Rolle des Product Owners wird, wie jene des Scrum Masters, von einer Person besetzt. Seine/ihre Aufgabe ist es, mit den Stakeholdern und Team zusammenzuarbeiten, um das Product Backlog aktuell und auf die Produktvision ausgerichtet zu halten.
Die Priorisierung der Arbeit im Product Backlog ist einzig die Aufgabe des Product Owners. Ziel der Priorisierung ist, durch den Einsatz des Teams möglichst viel Wert zu schaffen.
Das Entwicklungsteams (oder kurz: Teams) setzt sich aus 3-9 Personen zusammen. Dabei sind alle Disziplinen im Team vertreten, die benötigt werden, um aus einem Backlogitem ein Produktinkrement zu schaffen. In Scrum werden Teams etabliert, die über mehrere Sprints stabil bleiben.
Aufgabe des Teams ist es, innerhalb eines Sprints entlang der Prioritäten des Product Owners ein Produktinkrement zu schaffen. Dabei müssen die erledigten Arbeiten der „Definition of Done“ genügen, damit von einer einheitlichen Qualität der erledigten Arbeiten ausgegangen werden kann.
Wichtig ist, dass ein Produktinkrement eine Release fähige Qualität aufweist (d.h. zum Beispiel auch getestet und in das Gesamtsystem integriert wurde). Dies ist notwendig, damit die für die empirische Prozesskontrolle notwendige Transparenz entstehen kann.
Selbstorganisation ist ein wichtiges Prinzip von Scrum. Deshalb ist es auch die Aufgabe des Entwicklungsteams, die eigenen Hindernisse innerhalb des Teams selbst zu lösen.
Das Product Backlog ist eine priorisierte Liste an Arbeit für die Entwicklung eines Produktes. Es ist die „Single Source“ für Arbeit des Teams. Darin liegt der grosse Wert des Product Backlogs: Alle Arbeit des Teams ist an einem Ort festgehalten und transparent.
Ein Product Backlog ist ein lebendiges Artefakt, d.h. die enthaltenen Items werden konstant verfeinert, repriorisiert, entfernt oder neue Items werden ins Backlog aufgenommen.
Während des Sprint-Planning entscheidet das Team, in Rücksprache mit dem Product Owner, welche Items aus dem Product Backlog im nächsten Sprint bearbeitet werden. Diese Items werden im Sprint Backlog dargestellt und kontinuierlich abgearbeitet. Wie die Lösungsfindung erfolgt liegt im Ermessen des selbst-organisierten Teams.
Ziel eines Sprints ist die Erschaffung eines Produktinkrements. Dieses sollte eine „releasefähige“ Qualität aufweisen, d.h. spätestens nach dem Sprint Review auf Entscheid des Product Owners hin für den Markt freigegeben werden können.
Dieser Grad an Qualität ist notwendig, um spätere, unvorhersehbare Nacharbeiten zu vermeiden. So ist der Zustand des Produktes jederzeit transparent, was notwendig ist für den Erfolg der empirischen Prozesskontrolle (und somit des Teams).
Ein Sprint ist die Kadenz, in der das Scrum-Team plant und arbeitet. Dabei ist ein Sprint höchstens vier Wochen lang, wobei eine kürzere Dauer bevorzugt wird. Unmittelbar nach Ende eines Sprints folgt der Beginn des folgenden Sprints.
Die Sprint-Planung dient dazu, einen Forecast über die Arbeiten des kommenden Sprints zu machen. Dabei arbeitet das Team eng mit dem Product Owner, um die höchst priorisierten Items zu identifizieren und danach deren Lösung zu planen. Eine Sprint-Planung dauert maximal 8 Stunden bei einem 4-wöchigen Sprint (bei kürzeren Sprints entsprechend kürzer).
Während der Sprint-Planung wird das Sprint-Ziel festgelegt. Dieses gibt dem Team während dem Sprint Flexibilität in der Lösungsfindung, und gleichzeitig Sicherheit in Form von Leitplanken vor.
Am Sprint-Review wird das während dem Sprint erstellte Produktinkrement vom Team, Product Owner und Stakeholdern untersucht bzw. inspiziert. Insofern spielt der Sprint-Review eine wichtige Rolle in der empirischen Prozesskontrolle. Das Ergebnis der Inspektion wird im Backlog und/oder der nächsten Sprint-Planung berücksichtigt. Die Timebox für den Sprint-Review ist 4h für einen 4-Wochen-Sprint (entsprechend kürzer bei kürzeren Sprints).
An der Sprint-Retrospektive wird die Zusammenarbeit des Teams untersucht und notwendige Anpassungen identifiziert. Dabei arbeitet das Team eng mit Product Owner und Scrum Master zusammen. Beispielsweise identifiziert das Team Anpassungsbedarf bei der „Definition of Done“, um die Produktqualität weiter zu steigern.
Die Timebox der Sprint-Retrospektive ist 3h für einen 4-wöchigen Sprint (entsprechend kürzer bei kürzeren Sprints).
Der Daily Scrum dient der Förderung der Transparenz während eines Sprints. Es handelt sich um ein tägliches Treffen des Teams mit einer Timebox von 15 Minuten. Diese Zeit nutzt das Team um sich über den Stand der Arbeiten im Hinblick auf das Erreichen des Sprint-Ziels zu informieren und allfällige Hindernisse zu identifizieren.