Agiles Projektmanagement: Scrum Artefakte

Rollen, Meetings und Artefakte

Wie geölte Zahnräder eines Getriebes greifen im agilen Projektmanagement drei Rollen, vier Meetings und drei Artefakte ineinander. Sie müssen zusammen wirken, wollen sie nicht in einer Sackgasse landen.

Mit diesen Komponenten kommen Sie richtig in Fahrt in Ihrem agilen Projekt:

Rollen: Team, Scrum Master und Product Owner

Meetings: Sprint Planning, Daily Scrum, Sprint Review, Sprint Retrospective

Artefakte: Product Backlog, Sprint Backlog, Burn-Down Chart

Über Scrum-Rollen und Meetings berichtete ich in einem der vorangegangenen Beiträge.

Was aber sind Artefakte?

Artefakte dienen dazu, im Prozess der Softwareentwicklung die Übersicht zu behalten.

Mit ihrer Hilfe überwachen Produkt Owner, Scrum Master und Team die Arbeitsergebnisse während eines Sprints.

Sprint Backlog oder Sprint Burn-Down Chart stellen die zu leistenden Aufgaben übersichtlich und grafisch dar. Denn sie bilden den prozentualen Anteil der Vollständigkeit einer (Teil-) Funktion oder Lösung ab.

Somit repräsentieren Artefakte den Wert der geleisteten Arbeit. Im Scrum Guide, dem gültigen Leitfaden für Scrum, ist eine Allgemeingültige, aus meiner Sicht etwas sperrige, Beschreibung zu finden:

„Artefakte von Scrum repräsentieren Arbeit oder Wert, um Transparenz sowie Möglichkeiten zur Überprüfung und Anpassung zu schaffen.Die in Scrum definierten Artefakte wurden speziell so entworfen, dass sie die Transparenz der wesentlichen Informationen maximieren, um für alle ein gleiches Verständnis über das Artefakt zu schaffen.“

Product Backlog – digitales Treibhaus der Kundenwünsche

Der Product Owner entwickelt – gemeinsam mit den Stakeholder – die Anforderungen aus der Produktvision. Diese teilweise unscharfen Wünsche zerlegt er in kleine Häppchen und beschreibt diese mithilfe von User Stories.

Damit enthält das Backlog alle Anforderungen, die das zu realisierende Produkt (oder Funktion, oder Lösung) beschreiben. Die wichtigsten Anforderungen stehen ganz oben in der Liste.

Der Product Owner beschreibt sie so detailliert, wie es ihm der aktuelle Wissensstand erlaubt. Dann stehen sie dem Team zum Realisieren zur Verfügung. Ist etwas unklar, fragen sie gezielt nach. Oder sie ergänzen den Inhalt aufgrund ihres Sachverstandes selbstständig. Nun können die Teammitglieder den Realisierungsaufwand im Rahmen des Sprint Plannings, abschätzen.

Andere Anforderungen scheinen zunächst nebulös. Doch im Projektablauf erhalten sie mehr und mehr Gestalt. Aus den anfangs unreifen Wünschen, wächst nach jedem Sprint die Klarheit.

Der Product Owner schreibt nicht jede User Story selbst - das Team unterstützt ihn dabei. Jedoch entscheidet er, was in das Product Backlog aufgenommen und in welcher Reihenfolge es einsortiert wird.

Beim Product Owner verbleibt ein Veto Recht. Stimmt er allen Vorschlägen zu, wird sein Product Backlog zu lang. Deshalb zeigt er Grenzen auf: „Sorry, das gehört hier nicht rein“. Das Team bestimmt, wie viel User Stories aus dem Backlog in einem Sprint realisiert werden.

Sprint Backlog – teaminterne Aufgabenliste

Im Sprint Backlog versammelt das selbstorganisierte Team alle User Stories und Aufgaben, die sie in einem Sprint realisieren wollen.

Den Umfang der Arbeiten vereinbaren Product Owner und Team auf Basis von Schätzungen. Sie sind Ergebnis des Sprint Plannings. Die Teammitglieder nutzen das Backlog als simple ToDo-Liste. Nachdem die Liste initiiert wurde, pflegen und aktualisieren sie sie. Wie auch im Product Backlog stehen die wichtigsten Einträge ganz oben.

Beim Sprint Backlog entscheiden die Teammitglieder selbstständig, welche Einträge und wie viele sie in einem Sprint bearbeiten werden. Das Sprint Backlog ist ein lebendes Dokument, das heißt, neue Aufgaben kommen hinzu und erledigte oder depriorisierte Aufgaben fallen weg.

Neben dem Charakter einer Arbeitsliste besitzt das Backlog Prognose Charakter. Denn während des Sprints prognostizieren die noch unerledigten Arbeiten den Funktionsumfang, wie er dem Kunden zum Sprintende zur Verfügung stehen wird.

Grob gesagt, enthält das Backlog sowohl den Arbeitsvorrat für den aktuellen Sprint und somit eine fortlaufende Momentaufnahme über die geleistete Arbeit, als auch eine Vorschau, über die fertige Funktionen, die noch in dem Sprint bereitgestellt werden sollen.

Im Web finden Sie eine Reihe von Vorlagen, die Sie für Ihre tägliche Arbeit verwenden können. Das aussagekräftige Sprint Backlog enthält üblicherweise dieses Spalten:

• User Story
• Aufgaben
• Name des Bearbeiters
• Status
• Priorität
• Geschätzter Aufwand
• Verbleibende Arbeit
• Charakter (User Story oder Aufgabe etc.)

Alles im allem hilft das Sprint Backlog dem Selbstorganisierten Team die notwendige Arbeit zu planen und zu verwalten, um das Sprintziel zu erreichen. Das Team muss darauf achten, dass die Einträge immer aktuell sind. Denn was nützt die beste Liste, wenn sie veraltete Einträge enthält?

Burn-Down Chart – den Fortschritt kontrollieren

Das Team nutzt das Burn-Down-Chart, um sich über den verbleibenden Arbeitsaufwand in einem Sprint zu informieren. Aus dieser Grafik leiten sie die Geschwindigkeit ab, mit der sie die priorisierten User Stories aus dem Product Backlog abarbeiten - vorausgesetzt, es kommen keine neuen Aufträge hinzu.

Der Product Owner nutzt das Diagramm, um den Fortschritt seines Projektes zu überwachen. Da er mit den Kunden und Stakeholder ständig in Kontakt ist (das sollte er unbedingt) nutzt er die Informationen, um über den Projektfortschritt zu berichten.

So erhalten beide Interessengruppen das Gefühl, ob das Projekt in die richtige Richtung läuft. Nach dem ersten Sprint, hilft das Burn-Down Chart dem Product Owner einzuschätzen, wie viel Aufgaben das Team aus dem Product Backlog unter den gegebenen Rahmenbedingungen abarbeiten kann.

Wie beim Sprint Backlog auch, pflegen die Teammitglieder die Liste und nicht der Product Owner. Letztlich profitieren alle von den Vorteilen, die das Burn-down Chart bietet. Dazu zählen unter anderem:

Frühwarnsystem: Liefert ein sofortiges Verständnis über die Arbeit im Sprint. Liegen wir im Plan?  

Risikominderung durch tägliche Sichtbarkeit, da sofort sichtbar wird, sobald etwas schief geht.

Planungs- und Tracking-Tool für das Team, Scrum Master und Product Owner, da es tägliche Rückmeldungen über Aufwand und Zeitplan bietet

Kommunikationsinstrument für Kunden und andere Stakeholder

Platzhalter, um rückwirkende Aktionspunkte zu verfolgen

Abschließend ist zu bemerken, dass das Burn-down Chart für alle Beteiligten ein wertvolles Informations-, Planungs- und Steuerungsinstrument darstellt, da es Antworten auf diese Fragen liefert:

• Wie viel Arbeit kann das Team in der verfügbaren Zeit erledigen?
• Wann sind die geplanten User Stories abgeschlossen?
• Wann beendet das Team den aktuellen Sprint?
• Welche User Stories müssten für den nächsten Sprint priorisiert werden?