Das gibt es ja nicht, jetzt habe ich bereits in einigen Artikeln über agile Methoden (wie z.B. Scrum) geschrieben, aber über Scrum selbst bislang noch keinen Artikel verfasst. Das hole ich heute nach. Über agiles Arbeiten mit Methode kann man lange Ausführungen schreiben. Viele haben mittlerweile ihre eignen positiven, wie negative Erfahrungen damit gemacht. Um es vorweg zunehmen, meine sind durchweg positiv. Ich persönlich kam vor ca. 8 Jahren im Rahmen der Produktentwicklung zu agilen Methoden wie Scrum und Kanban. Diese Methoden, oder auch Management Frameworks, können universell eingesetzt werden. So kannst du Kanban für das Schreiben deiner Masterarbeit nutzen, deiner persönlichen Wochenplanung oder größere Projekte in deinem Unternehmen.

Scrum an sich ist kein Hexenwerk. Es ist als Methode sehr simple. Genau hier liegt auch die Gefahr. Denn schnell fängt man an, es methodisch zu verändern. Die Vorgehensweise wird immer skurriler und man hat nur noch ein ScrumBut.  Sprich, man fängt an erprobte Vorgehensweisen zu verändern und bringt sich, sein Team (und die Methode) ins Straucheln. Ein Beispiel für ScrumBut: „Ja, wir machen ein Daily, aber nur zweimal die Woche.“

Also, was brauchen wir alles für Scrum? Scrum besteht aus lediglich 3 Rollen.

Was ist Scrum die Grundzüge – Die Rollen – Sketchnote – VITAMINP.info

Die Rollen

• Development Team: Das Development Team ist ein interdisziplinäres Team, welches das Produkt entwickelt. Die Rolle ist bewusst universell gehalten, da jedes Team andere Experten benötigt. Scrum kann sowohl im HR Bereich eingesetzt werden, als auch in der Fertigung von Motoren und Smartphone Apps. Jedes dieser Teams benötigt andere Kompetenzen und Stärken.
• ScrumMaster (SM): Er/Sie ist verantwortlich für das Einhalten des Scrum Prozesses. Der ScrumMaster achtet darauf, dass das Team zusammenarbeitet und immer besser wird.
• Product Owner (PO): Der PO ist als Fachexperte verantwortlich für die Anforderungen. Er gibt die Vision vor und verantwortet das Geschäftsmodell dahinter.

Was ist Scrum die Grundzüge – Scrum Meetings – Sketchnote – VITAMINP.info

SCRUM Meetings/Events

Was ist eigentlich ein Sprint? Ein Sprint ist ein Entwicklungszyklus. In der Regel ist ein Sprint 2-3 Wochen lang. Im klassischen Projektmanagement durchläuft man die Phasen Initiation, Planning, Realization etc. einmal. Dies kann durchaus 6 Monate oder länger dauern. In Scrum durchläuft man diese Phasen in 2-3 Wochen für einen Teil der Anforderungen (User Stories).

• Planning: Im Planning Meeting werden die User Stories des kommenden Sprints festgelegt. Der Product Owner stellt die wichtigsten User Stories anhand des Product Backlogs vor. Das Development Team vergewissert sich, dass es das Ziel der jeweiligen User Story verstanden hat. Ggf. wird die User Story mit weiteren Informationen gefüllt. Das Planning ist beendet, wenn das Sprint Backlog gefüllt ist und das Development Team keine weiteren User Stories für den Sprint annimmt. Das Meeting wird durch den ScrumMaster moderiert.
• Daily Scrum: Das ist ein tägliches Status-Meeting. Es kommt das ganze Team zusammen, um sich gegenseitig den Status zu erläutern. Das Meeting dauert maximal 15 min. Der Product Owner ist nicht zwangsweise notwendig, es ist aber manchmal hilfreich, ihn/sie dabei zu haben.
• Review: Im Review stellt das Developer Team dem Product Owner seine Ergebnisse vor. Im Gegenzug bekommt das Dev. Team Feedback zum aktuellen Increment/Ergebnis. Die in dem Sprint umgesetzten User Stories werden vom PO abgenommen (oder nicht). Es können auch zusätzlich relevante Stakeholder eingeladen werden, die für den Erfolg des Produktes erfolgskritisch sind.
• Retrospective: Die Retrospektive ist zur Rückschau auf den Prozess zwecks kontinuierlicher Verbesserung notwendig. Der ScrumMaster moderiert das Meeting. Es wird erarbeitet, was in dem vergangenen Sprint oder in einem bestimmten Zeitraum gut oder schlecht war und es wird Verbesserungspotential identifiziert.

Was ist Scrum die Grundzüge – Scrum Artefakte – Sketchnote – VITAMINP.info

Die Artefakte

Klassischerweise werden Anforderungen in Lastenheften bzw. im Pflichtenheft beschrieben. In dieser agilen Vorgehensweise (Scrum) werden User Stories geschrieben. Diese User Stories beschreiben, wie der Name schon sagt, Teilanforderungen aus User/Anwender Perspektive. Am Beispiel „EC-Geldautomat“, könnte eine User Story das Geldabheben sein. Ausformuliert könnte diese wie folgt aussehen:

Als Kunde der Bank, möchte ich einen Teil meines Guthabens in Bar ausgezahlt bekommen, damit ich Bargeld für den Wochenend-Einkauf habe.

Die User Stories folgt einer gewissen Syntax. Wichtig für die Beschreibung sind  folgende drei Aspekte:

Als <Wer/Rolle>, möchte ich <das Ziel>, damit <den Grund für das Vorhaben>.

Wo werden die User Stories gesammelt?

• Product Backlog: Das Product Backlog umfasst alle User Stories für das Produkt. Hier stehen alle Aufgaben bzw. Anforderungen, die für das Produkt insgesamt umzusetzen sind. Hinweis: Die User Stories können weiter strukturiert werden. Z.B. via sog. Epics. Epics sind übergeordnete Themenbereiche, unter denen man User Stories subsumieren kann. Wichtig: Die User Stories in dem Product Backlog sind (idealerweise) immer priorisiert. D.h. die wichtigste User Story steht in der Liste ganz oben und die weniger Wichtigen unten.
• Sprint Backlog: Das Sprint Backlog umfasst alle User Stories für den laufenden Sprint. Das Sprint Backlog ist somit eine Teilmenge des Product Backlogs. Zu diesen hier genannten User Stories hat sich das Team im Planning Meeting gemeinsam entschieden. Es hat sich vorgenommen, all diese User Stories in dem Sprint zu erledigen.
• Increment: Als Increment bezeichnet man das Ergebnis des Sprints. Dies kann ein Increment oder mehrere Incremente sein. Die Incremente könne sich auch inhaltlich unterschieden. Z.B. kann ein Increment ein weiteres Kapitel deiner Masterarbeit sein, eine Weiterentwicklung einer vorhandenen App oder eine weitere konzeptionelle Iteration einer Vision sein.

Was ist Scrum die Grundzüge – Scrum Overview – Sketchnote – VITAMINP.info

Der Scrum Flow

Wie läuft jetzt ein Scrum Sprint ab? Wie spielen die Rollen, die Artefakte und die Meetings zusammen?

Zuerst benötigt man eine Idee. Dies kann eine Idee für ein Produkt oder generell ein Problem sein. Diese Idee sollte anderen vermittelbar sein. In der Regel vertritt diese Idee der Product Owner. Seine Aufgabe ist es das ganze Team mit seiner Idee zu begeistern.

Diese Idee (bleiben wir bei einer Produktentwicklung) wird in Einzelteile zerlegt, sogenannte User Stories. Diese User Stories sind Teilanfordeurngen an das resultierende Produkt. Diese werden in dem Backlog gesammelt. Die einzelnen User Stories sind in dem Backlog priorisiert und werden im Laufe der Zeit von oben nach unten abgearbeitet.

Iterativ zum Ziel // Der Sprint

Die Entwicklung zum Ziel erfolgt sprintweise. Das Team einigt sich, moderiert durch den ScrumMaster, auf eine Sprintlänge. Z. B. 2 oder 3 Wochen. Ein Sprint startet mit einem sog. Planning Meeting. In diesem Planning stellt der Product Owner die obersten User Stories im Backlog vor. Wenn sich das Development Team entscheidet User Stories umzusetzen, kommen diese in das Sprint-Backlog. Für den Vorgang sind zwei Punkte maßgeblich:

• Das Development Team muss den Sinn und die Zielsetzung der jew. User Storie verstanden haben
• Der Aufwand der User Storie muss geschätzt sein.  Denn nur so kann der ScrumMaster und das Team erkennen, wann ein Sprint-Backlog voll ist.

Das Schätzen der User Stories ist darüber hinaus noch wichtig für das Team selbst und die kontinuierliche Verbesserung. Durch den Schätzvorgang für eine Use Storie, lernt das Team die notwendigen Aufwände der einzelnen Personen/Kompetenzen kennen. Z.B. lernt ein Visual Designer die Entwicklungsaufwände eines App Entwicklers kennen und umgekehrt.

Was ist Scrum die Grundzüge – Scrum Flow – Sketchnote – VITAMINP.info

Den Fokus setzen

Wenn das Team sagt, dass das Sprint-Backlog ausreichend gefüllt ist, kann sich das Team noch ein Sprintziel setzen. Es bietet sich an, das Kern-Feature aus dem Sprint-Backlog zu nehmen oder ein Überthema, auf welches alle User Stories einzahlen. Ich persönlich finde die Idee für ein Sprintziel Motto für die Team-Motivation sehr wichtig, da sich das Team somit sehr gut auf die gemeinsame Zielerreichung einschwingt. Und das unahängig von der eigenen Rolle und Kompetenz. Alle zahlen gemeinsam auf das gleiche Ziel ein und arbeiten darauf hin. #Fokus

Jetzt kann der Sprint selbst starten. Ich persönlich habe die Erfahrung gemacht, dass vor dem formalen Start des Sprints, das Set-Up des Taskboards ein guter Startpunkt ist. Es wird ein Taskboard mit mindestens drei Spalten angelegt. Ich persönlich bevorzuge eine Metaplanwand mit Post-Its oder Moderationskarten. Die drei Spalten sind „New“, „in Progress“ und „Done“. In „New“ sind alle User Stories aufgelistet, die dieser Sprint beinhaltet. Sie werden in die Spalte „in Progress“ verschoben, wenn sich mind. einer der User Story animmt.  Die Story kommt in die Spalte „Done“, wenn sich das Development-Team einig ist, dass die User Story erfüllt wurde. Bei einigen (allen) User Stories empfiehlt es sich, hierzu Tasks anzulegen. Tasks sind Teilaufgaben, die in Summe die Erledigung der User Story abbilden. Ich persönlich empfehle Tasks, wenn die User Story selbst länger als ein Tag dauert und mehrere Personen daran arbeiten. Die Identifikation und Beschreibung der Tasks ist eigenverantwortlich die Aufgabe des Development Teams.

Kurzes Update bringt alle auf den aktuellen Stand // Das Daily

Der Sprint hat nun begonnen und das Team arbeitet selbstverantwortlich die User Stories ab. Das Development Team trifft sich einmal täglich im sogenannte Daily. Das Daily ist für max. 15 min. angesetzt und wird vom ScrumMaster moderiert. Der Product Owner ist nicht zwangsweise dabei. Es bietet sich an, ihn manchmal dabei zu haben. Jedes Development Teammitglied gibt seinen Kurzzstatus ab. Hierzu empfiehlt sich die Orientierung an folgenden drei Fragen:

• Was habe ich gemacht? In dem Zeitraum vom letzten Daily bis jetzt.
• Was werde ich machen? Von jetzt an bis zum nächsten Daily.
• Was sind meine Impediments? Welche Hürden habe ich zu meistern oder benötige ich Hilfe zur Erledigung mancher User Stories?

In dem Daily oder direkt danach werden die User Stories bzw. die entsprechenden Tasks auf dem Taskboard verschoben.

Zeigt her was ihr habt // Das Review

Am Ende des Sprints gibt es Review Meetings. Hier nimmt das gesamte Scrum Team teil. Das Development Team stellt dem Product Owner die Ergebnisse der Stories vor. Der Product Owner nimmt diese ab, oder eben auch nicht. Sollte eine User Story nicht fertig sein, kommt diese zurück in das Backlog. Das Review ist in der Regel ein offenes Meeting. Es empfiehlt sich hier weitere Interessenten und Stakeholder einzuladen. Als Richtwert für die Planung des Reviews, empfehle ich 1h pro Wochenlänge des Sprints. D.h. wenn dein Sprint 2 Wochen dauert,  kannst du mit 2h Review beginnen. Du merkst nach 2-3 Reviews, wie viel Zeit du wirklich benötigst.

Da bei dem Review gerne auch Personen dabei sind, die nicht im Scrum Team sind, ist eine gute Moderation durch den ScrumMaster gefragt. Hier gehört ein gewisses Fingerspitzengefühl dazu, dass zum Einen die User Stories vorgestellt werden und das Meeting selbst, durch zuviele Nachfragen, nicht aus dem Ufer gerät. Im Zweifel sind alle Gäste „nur“ Zuhörer und das ScrumTeam hat das „Rederecht“. Ggf. kann man im Anschluss eine gewisse Zeit für Fragen, Anregungen etc. reservieren. Feedback ist wichtig, es sollte nur nicht in verwässernde, nicht zielführende Diskussionen ausarten.

Nach dem Sprint ist vor dem Sprint // Die Retrospektive

Bevor der neue Sprint beginnt, steht die Retrospektive an. Dieses Meeting ist eines der wichtigsten Meetings, da es der kontinuierlichen Verbesserung des Teams dient. Klassischerweise besteht das Meeting aus zwei Teilen.

1. Es werden Informationen erhoben, welche das Team bewegt.
2. Es werden Maßnahmen zu Verbesserung abgeleitet.

Der ScrumMaster kann für die Retrospektive ein Thema vorgeben oder generell nach Stimmungsbildern und Anliegen im Team fragen.

Soweit die Theorie. Was denkst du? Passt Scrum und das agile Vorgehen auch zu dir, zu deinem Projekt? Probiere es einfach mal aus. Ein erster Einstieg kann das Organisieren deiner persönlichen Tasks mit einem Taskboard sein.