Share ZU:
1 May 2012 @ Susanne Mühlbauer

Mit Scrum mehr Meetings und Administration?

Befragt man Entwicklungsteams und andere Beteiligte im Unternehmen, was sich seit der Einführung von Scrum geändert hat, erhält man überraschend oft die Aussage: Wir haben jetzt noch mehr Meetings und mehr Aufwand für Administration. Das ist erstaunlich. Woher kommt dieser Eindruck? Sehen wir uns doch die Scrum Meetings (oder gemäß Scrum Guide die „Events“) einmal genauer an.

Bei einem vierwöchigen Sprint gibt es folgende Empfehlungen:

Sprint Dauer(4-Wochen Sprint)
Sprint Planning Meeting 2 x 4 Stunden Time-Box
Daily Scrum 15 min Time-Box
Sprint Review Meeting 4 Stunden Time-Box
Sprint Retrospective Meeting 3 Stunden Time-Box
Backlog Refinement/ Grooming 10% des Sprints

Diese Meetings bzw. Events nehmen ca. 25 % der Entwicklungszeit ein. Das klingt tatsächlich nach viel Administrationsaufwand. Um das genauer zu verstehen, betrachten wir nun Ziele und Aufgaben der einzelnen Events.

Das Sprint Meeting

Das Sprint Planning Meeting besteht aus zwei Teilen: Planning Meeting 1 gehört dem Product Owner. Er stellt die geplanten Inhalte für den anstehenden Sprint vor, also WAS umgesetzt werden soll und beantwortet letzte Fragen. Das Meeting dient also der Anforderungsanalyse.

Planning Meeting 2 gehört dem Entwicklungsteam. Das Ziel des Meetings ist es, das Software-Design für den kommenden Sprint zu entwickeln und zu entscheiden, WIE die Umsetzung zu erfolgen hat. Es ist ein weiteres AnalyseMeeting und dient dem Design. Als Nebenprodukt dieses Meetings werden die Tasks, die Bearbeitungsaufgaben des Teams, erstellt. Hier erfolgt also ein Teil der Projektplanung – quasi nebenbei.

Der Daily Scrum ist ein Inspektions- und Adaptionsmeeting. Es dient dazu, Hindernisse zu erkennen, Entscheidungen zu treffen und liefert über das Projekt und den Projektfortschritt für alle. Es unterstützt das Projektmanagement, weitere Abstimmungsmeetings entfallen.

Das Sprint Review Meeting beinhaltet die Abnahme (oder Ablehnung) der erstellten Ergebnisse und dient zur Erhebung weiterer Anforderungen. Es ist also ebenfalls ein Teil des Requirements Engineerings.

Das Retrospective Meeting dient der Prozessverbesserung. Es ist also ebenfalls kein Administrationsmeeting.

Die Tätigkeiten aus dem Backlog Refinement/ Grooming dienen wiederum der Anforderungserhebung und Anforderungsanalyse.

Damit stellen sich die vermeintlichen Meeting bzw. Administrationsaufwände wie folgt dar:

Sprint Dauer(4-Wochen Sprint) Ziel
Sprint Planning Meeting 2 x 4 Stunden Time-Box Anforderungsanalyse, Software-Design, Projektplanung
Daily Scrum 15 min Time-Box Projektplanung und -management
Sprint Review Meeting 4 Stunden Time-Box Abnahme, Anforderungserhebung
Sprint Retrospective Meeting 3 Stunden Time-Box Prozessverbesserung
Backlog Refinement/ Grooming 10% des Sprints Anforderungserhebung, Anforderungsanalyse

Sehen wir uns die prozentuale Verteilung an, zeichnet sich daher folgendes Bild:

Requirements Engineering: ca. 20 %

Das beinhaltet Anforderungserhebung, Anforderungsanalyse, Design und Abnahme

Projektmanagement und Prozessverbesserung: ca. 5%

Der Eindruck, dass Scrum zu mehr Meetings und Administrationsaufwand führt, ist daher nicht gerechtfertigt. Vielmehr sollten die Scrum Master verstärkt darauf achten, dass allen Beteiligten, also nicht nur den Entwicklungsteams sondern auch der ganzen Organisation, die Ziele und erwarteten Ergebnisse der Scrum Events klar sind.

Möchten Sie mehr zum Thema Scrum und RE erfahren?
Dann empfehle ich eines unserer beliebten Trainings, wie beispielsweise das zum  Certified Agile Requirements Specialist (CARS), zum Scrum Master,  den Intensivworkshop zur IREB® CPRE-Foundation Level Zertifizierung,  oder CPRE Advanced Level . Es ist bestimmt etwas für Sie dabei.

Susanne Mühlbauer

Kontaktieren Sie Susanne Mühlbauer

Susanne Mühlbauer ist als Agile Coach für die HOOD GmbH tätig. Sie arbeitet mit Leidenschaft und viel persönlichem Engagement mit Menschen, Teams und Organisationen auf ihrem Weg zu mehr Agilität. Aus ihrer Zeit als Consultant, Scrum Master, Projektleiter, Business Analyst und Requirements Engineer bringt sie langjährige Erfahrungen und die unterschiedlichsten Erlebnisse aus dem Projektgeschäft und in der Entwicklung komplexer Produkte und Systeme mit. Ein Schwerpunkt stellt hierbei sicherlich das Requirements Engineering dar. Sie hat zu diesen Themen Artikel veröffentlicht und ist gerne Referentin auf Fachkongressen. Ihr Leitsatz: Agilität muss man erleben. Hierfür steht Agile-by-HOOD.