Kayenta

Agiles Projektmanagement: Scrum Artefakte

Agiles Projektmanagement: Scrum Artefakte
Product Backlog, Sprint Backlog und Burn-Down Chart in Scrum

Scrum ist eine Sammlung von Rollen, Meetings und Artefakte. Also selbst das agile Projektmanagement braucht einen regelnden Rahmen.

Doch Scrum überlässt seinen Anwendern zu entscheiden, welche Komponenten sie nutzen wollen. Artefakte helfen, die Übersicht in der Aufgabenflut zu behalten, Arbeitsergebnisse zu planen und zu überwachen.

Lesen Sie in diesem Beitrag, welche Rolle Product Backlog, Sprint Backlog und Burn-Down Chart in Scrum übernehmen.

 

 

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 dem 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 diese. 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 in 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 schiefgeht.

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?

Über den Autor

Werner Plewa
Projektmanager

Experte für berufliche Weiterbildung und Personalentwicklung. Kontaktanfrage gerne auch bei LinkedIn:


Weitere Artikel

Daily Scrum Meeting - Stand-Up Meeting im agilen Projektmanagement

Das Daily Scrum Meeting findet täglich statt. Für den reibungslosen Ablauf ist der Scrum Master verantwortlich. Für das Team und für den Scrum Master ist die Anwesenheit Pflicht.

Lesen Sie, welche Faktoren das Daily Scrum Meeting kennzeichnen. Und was Sie beachten sollten, damit es erfolgreich verläuft.

Projektmanagement: klassisch oder agil? Welches Modell passt zu meinem Projekt?

Klassische und agile Vorgehensmodelle haben sich im Projektmanagement etabliert. Der folgende Beitrag macht die Unterschiede sichtbar, indm er Prozessablauf, Akteure sowie die verwendeten Werkzeuge beider Welten beleuchtet.

Agiles Projektmanagement - Werte und Prinzipien

In diesem Beitrag beschäftige ich mich mit der Frage: Projekte agil managen - kann das jeder? Wie muss man „sein“, um die Projektarbeit erfolgreich zu gestalten? Es geht um Mut und Offenheit, Respekt und Prinzipien im agilen Arbeitsumfeld.

In meinem letzten Beitrag "Projektmanagement: klassisch oder agil?" berichtete ich über die Unterschiede zwischen traditionellen und agilen Projektmanagement. Dabei beleuchtete ich die Verfahren, die Akteure und die Werkzeuge beider Welten.

In diesem Beitrag geht es um die Werte wie Mut und Offenheit, Respekt und Prinzipien im agilen Arbeitsumfeld. Lesen Sie einen ganz persönlich gefärbten Beitrag.

Kayenta Logo
KAYENTA® Training und Beratung
Abendrothsweg 73
20251 Hamburg
Telefon.: +49 40 370 80 155
E-Mail: kontakt@kayenta.de
KAYENTA Training Projektmanagement hat 4,67 von 5 Sternen 2203 Bewertungen auf ProvenExpert.com
© 2024 KAYENTA® Training und Beratung | Impressum | Datenschutz | AGB | Telefon.: +49 40 370 80 155