Scrum

Scrum ist eine agile Projektmanagement-Methode, die darauf abzielt, Teams dabei zu unterstützen, effektiv und effizient zu arbeiten. Es basiert auf einem iterativen Ansatz, bei dem Arbeit in kurzen Zeitspannen, sogenannten Sprints, organisiert wird. Scrum legt grossen Wert auf enge Zusammenarbeit, Transparenz und kontinuierliches Feedback zwischen Teammitgliedern, Stakeholdern und dem Kunden. Die Scrum-Rollen umfassen den Product Owner, der die Anforderungen des Kunden priorisiert, den Scrum Master, der das Team unterstützt und Hindernisse beseitigt, und das Entwicklungsteam, das die Aufgaben plant und umsetzt. Durch regelmässige Meetings wie das Daily Scrum, das Sprint Planning und die Sprint-Review werden Fortschritte überprüft, Herausforderungen bewältigt und kontinuierliche Verbesserungen ermöglicht.

Vorgehen

Sprint

Ein Sprint dauert 3 Wochen, in diesem arbeitet das Dev-Team an den Storys des*der Product Owner. Dabei finden diverse Sitzungen statt, welche nötig sind, um die Inhalte der Vision zu er-/bearbeiten.

Inkrement

In Zusammenarbeit mit Menschen, die sich ehrenamtlich engagieren, kann die Dauer von 4 Wochen sehr kurz sein. Daher dauert ein Inkrement 3 Sprints. Mehr dazu findest du unter Agilität in der Jubla.                                              

Arbeitsinstrumente

Story

Eine Story beschreibt einen Zustand/Ziel, der/das erreicht werden soll. Eine Story, kann prinzipiell von jedem erstellt werden, der*die Product Owner, hat die Verantwortung, dass diese allen Anforderungen entspricht, damit diese umgesetzt werden kann.

Die Anforderungen an eine Story sind:

1. Unabhängig: Die Story sollte in sich abgeschlossen sein und unabhängig von anderen Storys umgesetzt werden können.

2. Verhandelbar: Die Details der Story können im Team diskutiert und verfeinert werden, um eine gemeinsame Verständigung zu erreichen.

3. Wertvoll: Die Story sollte einen klaren Wert für die Mitglieder oder Benutzer*in liefern und einen Beitrag zum Erreichen der Projektziele leisten.

4. Schätzbar: Das Dev-Team sollte in der Lage sein, den Aufwand für die Umsetzung der Story zu schätzen.

5. Klein: Die Story sollte klein genug sein, um innerhalb eines Sprints abgeschlossen werden zu können, typischerweise zwischen einer und drei Wochen.

6. Testbar: Die Story sollte klare und messbare Akzeptanzkriterien enthalten, um sicherzustellen, dass die Umsetzung erfolgreich abgeschlossen ist.

Die Story hat immer den gleichen Aufbau:

• Die User-Story selbst. Diese ist folgendermassen aufgebaut: 

  Als [Person] [möchte] ich, [damit].
  Die Story wird aus Sicht der nutzenden Person geschrieben. Auch erklärt sie, was die Person erreichen möchte und wieso. Anhand dieser Punkte fällt es dem Dev-Team einfacher, nach Lösungen zu suchen und die optimale davon für die Umsetzung zu wählen. 

• Akzeptanzkriterien (Definition of Done)
  Akzeptanzkriterien sind spezifische Bedingungen oder Anforderungen, die festlegen, wann eine Story als abgeschlossen betrachtet werden kann. Sie dienen dazu, klare und messbare Standards für die Akzeptanz eines fertigen Arbeitsergebnisses festzulegen. Indem sie klare Richtlinien liefern, ermöglichen Akzeptanzkriterien eine einheitliche Beurteilung der Arbeit und fördern die Transparenz und das Verständnis innerhalb des Scrum-Teams.

• Schätzung der Umsetzung
  Die Schätzung beinhaltet die Zeit, die benötigt wird, um die Story so zu erfüllen, dass die Akzeptanzkriterien erfüllt werden. Sie wird durch das Dev-Team erstellt und für das Sprint Planning benötigt.

Dieses Ziel muss innerhalb eines Sprints/Inkrement umsetzbar sein. Ansonsten muss die Story so gesplittet werden, dass diese in der vorgegebenen Zeit umsetzbar sind.

Backlog

Das Backlog sammelt alle Storys, des Produktes/Thema. Es kann mit einem Ideenpool verglichen werden, das alles sammelt, was toll wäre, wenn es er/-bearbeitet werden würde. Die Priorisierung innerhalb des Backlogs spiegelt auch die Reihenfolge ab, in dem die Inhalte bearbeitet werden. Je weiter oben eine Story ist, desto wichtiger ist sie. Storys mit einer hohen Priorität sind so spezifiziert, dass diese in nächsten Sprint Planning in für den Sprint ausgewählt werden können.

Kanban Board

Das Kanban Board unterstützt alle (Dev-Team, Scrum-Master, Product Owner) die Übersicht zu behalten. Es besteht aus vier Spalten; Backlog, To Do, Doing, Done.

Die Storys sind jeweils in der entsprechenden Spalte, in dessen Status sie sich gerade befinden. Jede*r im Team ist zuständig, das Board aktuell zu halten. Jede*r führt die Status für die Storys nach, die er*sie gerade bearbeitet.

Mehr zum Thema Kanban findest du auch hier.

Rollen

Ein Scrum-Team besteht aus mehreren Personen, die unterschiedliche Rollen einnehmen. Idealerweise nimmt keine Person mehrere Rollen ein.

Scrum Master

Als Scrum-Master liegt es in deiner Verantwortung, das Dev-Team so zu unterstützen, dass sich dieses auf seine Hauptaufgabe konzentrieren kann. Du koordinierst und organisierst die Dailys/Weeklys, moderierst die unterschiedlichen Gefässe und unterstützt, wo möglich. Umsetzen der Story-Inhalte gehört jedoch nicht dazu.

Product Owner

Als Product Owner (kurz PO), bist du der*die Ansprechpartner*in des Dev-Teams und der Personen, die ein Anliegen/Wunsch zu dem Produkt haben. Das Produkt muss dabei nicht zwingend etwas Physisches oder Digitales sein. Die Rolle ist als Themenhüter*in zu verstehen. Du hast die Hoheit über das Backlog und definierst die Priorität, in welcher Storys vom Dev-Team angegangen werden. Es ist deine Aufgabe, die Storys zu schreiben, dass diese bei Sprintbeginn genug klar sind, dass das Dev-Team diese umsetzen kann, ohne dass es während des Sprints Rücksprache mit dir nehmen muss.

Dev-Team-Mitglied

Als Mitglied eines Dev-Teams (Dev – Kurzform für das englische Wort Developer: Entwickler*in) setzt du die Storys um, zu denen sich das Team für den aktuellen Sprint committet hat. Das Team ist meist interdisziplinär und hat von allen nötigen Kompetenzen jemand mit an Bord. Die Zusammensetzung des Teams kann von Sprint zu Sprint ändern, da immer nur die Personen mit dabei sind, die es für die Erreichung des Sprintziels benötigt (Ressourcenschonung).

Gefässe

Im Scrum gibt es diverse Gefässe (Sitzungen), mit unterschiedlichem Zweck. Alle Gefässe finden mindestens einmal pro Sprint statt.

Refinement

An dieser Sitzung schaut sich das Dev-Team die Storys des PO an und prüft, ob diese anhand der Story-Beschreibung so umsetzbar sind. Das Dev-Team kann Storys, die nicht genügend spezifiziert sind, wieder dem PO zurückgeben. Ziel dieser Sitzung ist es ein gemeinsames Verständnis des geforderten Storyziels zu entwickeln und dass diese Ready für das Sprint Planning ist.

Sprint Planning

Im Sprint Planning entscheidet das Dev-Team, welche Storys im nächsten Sprint umgesetzt werden. Dabei berücksichtigt es, wie viel Kapazität es hat (Wie viele Tage pro Woche, kann jede*r am Ziel arbeiten? Wer hat welche Abwesenheiten während des Sprints?) und nimmt diese Story in den Sprint. Da hinter jeder Story auch eine grobe Schätzung des Aufwands ist, kann sichergestellt werden, was mit der zur Verfügung stehenden Ressourcen in diesem Sprint umsetzbar ist. Die Storys, zu denen sich das Dev-Team committet, gelten als Sprintziel und das Dev-Team sollte alles daran setzen, dieses auch zu erreichen. Diese Storys werden im Kanban-Board in die Spalte To Do verschoben.

Sobald der Sprint gestartet ist, dürfen keine neuen Storys dem Sprint hinzugefügt werden. Die höchste Priorität hat es zuerst alle offenen Storys abzuschliessen, bevor neue Storys in den Sprint bearbeitet werden.

Daily/Weekly Stand-up

Ein Daily ist eine tägliche Sitzung von maximal 15 Minuten. Stand-up heisst es darum, weil alle Anwesenden stehen (sobald man sitzt, dauern Sitzungen meist länger). An der Sitzung nimmt das Dev-Team und der*die Scrum-Master teil. Jede Person des Dev-Teams berichtet, was er*sie gestern erledigt hat, was er*sie sich heute vornimmt und wo er*sie gerade ansteht. Ziel davon ist es, dass das gesamte Team eine Übersicht erhält, wer an was gerade dran ist. Dadurch haben alle einen Überblick, wie das Team auf dem Weg zur Sprint-Ziel-Erreichung liegt und allfällige Synergien können genutzt werden. Wichtig: Am Stand-up finden keine bilateralen Gespräche statt. Diese sind zwingend auf nach dem Meeting zu verschieben.

Arbeitet das Dev-Team nicht mehrmals pro Woche am Projektinhalt, macht ein tägliches Treffen meist keinen Sinn. In diesem Fall kann ein Weekly oder sogar Bi-Weekly (wöchentliches oder 2-wöchentliches Treffen) organisiert werden.

Review

Das Review ist öffentlich und das Dev-Team präsentiert, was es im letzten Inkrement erreicht hat. Ziel ist es hier (sofern möglich) keine PowerPoint-Präsentation zu halten oder die Art und Weise zu präsentieren, wie man vorgegangen ist, sondern viel mehr, was das nutzbare Resultat für den Verband ist. Dies soll in einer Demonstration durch das Dev-Team (also die, die das umgesetzt haben), präsentiert werden.

Retro

An der Retro nehmen alle des Scrum-Teams teil. Auch dieses Meeting wird vom Scrum-Master moderiert. Üblicherweise findet dieses Meeting gleich nach dem Review statt. Statt des Inhaltes wird nun die Zusammenarbeit reflektiert. Es gibt dabei unterschiedliche Methoden. Ziel ist es, dass die Zusammenarbeit im Team optimiert wird, damit es noch effizienter arbeiten kann.