Bürowahnsinn#3 – Unser agiles Entwickler Team im Scrum-Versum

Der langfristige Plan (Product Backlog) wird kontinuierlich verfeinert und verbessert. Der Detailplan (Sprint Backlog) wird nur für die anstehende Iteration (Sprint) definiert. Scrum besteht aus nur wenigen Regeln. Diese Regeln beschreiben fünf Aktivitäten, drei Artefakte und drei Rollen.

Der Product-Owner definiert die fachlichen Anforderungen und priorisiert diese stetig (Product-Backlog). Vor jedem Sprint wählt der Product-Owner eine oder mehrere Funktionen bzw. Anforderungen aus dem Product-Backlog. Diese Backlog Items werden dann vom Entwickler-Team im Detail geplant (Sprint-Backlog) und innerhalb eines Sprints umgesetzt. Der Scum-Master koordiniert das Team, coacht Product-Owner und Team, verfeinert Prozesse und achtet darauf, dass alle Regeln eingehalten werden. Das Entwickler-Team, i. d. R. bestehend aus 5-10 Personen, organisiert sich selbst. Größere Gruppen können in mehrere unabhängige Teams aufgeteilt werden.

Der Product-Owner definiert die fachlichen Anforderungen und priorisiert diese stetig (Product-Backlog). Vor jedem Sprint wählt der Product-Owner eine oder mehrere Funktionen bzw. Anforderungen aus dem Product-Backlog. Diese Backlog Items werden dann vom Entwickler-Team im Detail geplant (Sprint-Backlog) und innerhalb eines Sprints umgesetzt.

Ein wichtiges Konzept, das in Scrum angewendet wird, ist das Time-Boxing. Time-Boxing sind Zeitabschnitte, die nicht überschritten werden dürfen. Arbeiten, Besprechungen und Termine finden alle zu einem festgelegten Zeitpunkt statt. Die Dauer ist ebenfalls geplant und muss unbedingt eingehalten werden. Durch Time-Boxing können sich alle Beteiligten bestmöglich auf das Wesentliche konzentrieren und sich auf ihr Ziel fokussieren.

Zu Beginn eines jeden Sprints findet das Sprint-Plannig statt. Auch hier ist das Time-Boxing unbedingt einzuhalten. Im ersten Teil des Sprint-Plannings stellt der Product-Owner das aktuelle Product-Backlog und die Backlog-Items mit der höchsten Priorität vor. Darüber hinaus wird oft auch ein übergeordnetes Sprint-Ziel mit dem Entwickler-Team vereinbart. Dies kann zum Beispiel das Veröffentlichen einer neuen Version mit den neuen Funktionen (Product Increment) am Ende des Sprints sein.

Nachdem im ersten Teil des Sprint-Plannings das „Was“ definiert wird, geht es im zweiten Teil um das „Wie“. Das Entwickler-Team plant autonom die Umsetzung der ausgewählten Anforderungen im Detail. Komplexe Ausgaben werden in kleinere Teilaufgaben unterteilt, der Aufwand in Zeit geschätzt und mit einer detaillierten Beschreibung als Task im Sprint-Backlog angelegt.

Sobald das nächste Inkrement, der anstehende Sprint, vorbereitet ist, kann der Sprint gestartet werden. Aufgrund der Plannings ist der Inhalt eines Sprints genau festgelegt. Jeder Sprint hat eine genau definierte Länge. Das Entwickler-Team arbeitet innerhalb der vorher definierten Time-Box das Sprint-Backlog ab. Dabei organisiert sich das Team selbst. Während des Sprints wird das Team nicht durch neue Aufgaben oder veränderten Anforderungen gestört. Dadurch wird das konzentrierte Arbeiten gefördert und der Fokus auf das Sprint-Ziel stets beibehalten.

Während des Sprints wird regelmäßig das Burndown-Chart kontrolliert. Das Burndown-Chart zeigt den aktuellen Fortschritt des Sprints an und zeigt auf, wie viel Arbeit nach aktueller Schätzung zu jedem Zeitpunkt noch übrig ist, um das aktuelle Sprint-Ziel zu erreichen. Drohende Abweichungen vom Zeitplan lassen sich so schnell erkennen.

Während des Sprints trifft sich das Entwickler-Team täglich zum Daily-Scrum.

Dieses kleine Meeting sollte nicht länger als 15 Minuten (Time-Boxing) andauern und wird in der Regel im Stehen abgehalten. Hier stimmt sich das Entwickler-Team ab und informiert sich gegenseitig über die neuesten Entwicklungen oder aufgetretenen Probleme. Folgende Fragen sollten thematisiert werden:

• Was habe ich seit dem letzten Daily Scrum getan, um das Projekt voranzubringen?


• Was plane ich, bis zum nächsten Daily Scrum zu tun, um das Projekt voranzubringen?


• Was hat mich bei der Arbeit behindert (Impediments)?

Der anwesende Scrum-Master notiert sich aufgetretene Impediments. Der Product-Owner kann sich über den aktuellen Stand informieren und ggf. Rückfragen beantworten. Er sollte sich nicht unaufgefordert im Geschehen einmischen.

Am Ende jedes Sprints präsentiert das Entwickler-Team dem Product-Owner in der Sprint-Review die erbrachten Ergebnisse live am System. Hier wird komplett auf Dummies (PowerPoint etc.) verzichtet. Sämtliches Feedback ist erwünscht und wird inkl. Kritik und Verbesserungsvorschlägen notiert. Der Product-Owner entscheidet aufgrund des Gezeigten, ob das neue Inkrement produktiv gesetzt wird oder weiter entwickelt werden muss.

Nach der Sprint-Review findet die Sprint-Retrospektive statt. In dieser Besprechung, welche vom Scrum-Master moderiert wird, diskutiert das Team rückblickend den abgeschlossenen Sprint. Alle im Sprint aufgetretenen Impediments werden in ihrer Ursache und den Folgen analysiert. Es werden Maßnahmen besprochen, um diese künftig zu verhindern. Was ist gut gelaufen? Was ist schlecht gelaufen? Was könnte man tun, um den nächsten Sprint noch produktiver oder angenehmer zu gestalten?

Das Product-Backlog Refinement ist ein fortlaufender Prozess, bei dem der Product Owner und das Entwicklungsteam gemeinsam das Product Backlog weiterentwickeln. Dazu gehören folgende Schritte:

• Ordnen der Einträge


• Löschen von Einträgen, die nicht mehr wichtig sind


• Hinzufügen von neuen Einträgen


• Detaillieren von Einträgen


• Zusammenfassen von Einträgen


• Schätzen von Einträgen


• Planung von Releases

Wir wollten Euch erst einmal einen Eindruck vermitteln, was Scrum eigentlich ist. In dem Zusammenhang halten wir Euch zukünftig auf dem Laufenden darüber, welchen Vorteil Scrum gegenüber Kanban für unser Entwickler-Team hat und wie es sich bei uns implementiert hat.

>> Bis dahin erfahrt mehr darüber, wie Kanban unser Team im Online-Marketing bereichert.