Backlog
Ein Begriff, der im Zusammenhang mit Scrum und Kanban immer wieder verwendet wird, ist das sogenannte Backlog. Oftmals ist dabei die Rede von den Backlog Items eines Product Backlogs oder von einem Sprint Backlog und User Stories als Quelle für das Backlog.
Doch wofür stehen diese Begriffe eigentlich genau und wie kann der Backlog dazu beitragen, einen Überblick und eine Priorisierung über ein Projekt zu schaffen und den Arbeitsrückstand aufzuzeigen?
Backlog Bedeutung: Was versteht man unter diesem Begriff?
Das Backlog ist eine wichtige Methode im Rahmen von Scrum. Ganz allgemein wird damit im Projektmanagement ein Nachholbedarf beziehungsweise ein Arbeitsrückstand bezeichnet, der sich im Laufe der Zeit angesammelt hat.
Beim agilen Projektmanagement bezeichnet der Produkt Backlog alle Aufgaben im Projekt , die noch zu erledigen sind. Diese Aufgaben werden in Form einer Liste als sogenannte Backlog Items mit allen erforderlichen Informationen wie etwa der Priorität sowie dem geschätzten Umsetzungsaufwand dargestellt.
In weiterer Folge wird diese Liste mit den Anforderungen dem Entwicklungsteam (dem Scrum Team) zur Verfügung gestellt und ist ein wichtiges Tool in jedem Sprint Review Meeting.
Wie entsteht ein Backlog bei Scrum?
Die Basis für die Erstellung eines Product Backlogs bilden die sogenannten User Stories. Sie begleiten agile Projekte vom Anfang bis zum Ende. Basis dafür ist die Anforderung, die ein Kunde und gegebenenfalls andere Partner an das Entwicklerteam stellt.
Der vollständige Produkt Backlog ist dann im Grunde genommen nichts anderes als die vollständige Liste aller noch zu bearbeitenden User Stories, die dort als Produkt Backlog Items inklusive Aufwandsschätzung und entsprechender Priorisierung zu finden sind.
Was ist mit User Stories gemeint?
Bei den User Stories handelt es sich um eine einfache Definition einer bestimmten Eigenschaft. Im Rahmen der Softwareentwicklung werden diese als sogenannte Features bezeichnet.
Die User Stories werden vom Team aus der Perspektive des jeweiligen Endnutzers formuliert. Dabei kann es sich um die unterschiedlichsten Dinge handeln, zumeist betrifft es aber ein neues Produkt oder eine neue Dienstleistung oder einen Teil davon.
Oftmals werden die User Stories auf Post-Its verfasst und dann an das Product Backlog beispielsweise auf ein Whiteboard oder eine Pinnwand gehängt. Von dort kann das gesamte Team die Aktivitäten überblicken.
Somit wird schnell sichtbar, welche Arbeiten grundsätzlich zu erledigen sind und in weiterer Folge auch, in welcher Reihenfolge bzw. Priorisierung sie bearbeitet werden sollen und wieviel Zeit sie dabei in Anspruch nehmen werden.
Ein großer Vorteil von User Stories ist, dass mit ihnen unterschiedlich tief auf ein Thema eingegangen werden kann. Sind die User Stories zu groß, können sie vom Entwicklungsteam auch in kleinere Aufgaben für den Product Backlog unterteilt werden.
Eine User Story mit der Erledigung einer großen Aufgabe wird im Scrum als „Epic“ bezeichnet. Ein „Epic“ kann dabei auch aus Dutzenden von Aufgaben bestehen. Der Aufbau bleibt dabei jedoch immer gleich.
User Stories im Backlog bestehen aus drei Fragen: Wer? Was? Warum?
Grundsätzlich müssen vollständige User Stories im Backlog zumindest die folgenden drei Fragen beantworten:
| Wer? | Damit ist gemeint, wer von den einzelnen Items im Product Backlog profitiert. In den meisten Fällen handelt es sich dabei um den Endkunden, es kann aber auch ein Lieferant oder ein interner Mitarbeiter oder ein Kollege innerhalb des Scrum Teams sein. Beispielsweise könnte es darum gehen, als Zulieferer für einen Automobilhersteller das Blinkersystem für ein neues Automodell zu designen. |
| Was? | dessen, was entwickelt werden soll. Dabei kann es sich um ein vollständiges Produkt oder eine Dienstleistung handeln oder auch nur um einen Teilaspekt davon. Es kann also ein komplettes Auto, das ganze Lichtsystem oder auch nur der Blinker gemeint sein. |
| Warum? | Bei der Frage nach dem Warum soll beantwortet werden, warum das Produkt oder die Dienstleistung angeboten werden soll. Ein Auto, das im Straßenverkehr fahren soll, benötigt beispielsweise Blinker, um zum einen den Anforderungen der Straßenverkehrsordnung gerecht zu werden und zum anderen den anderen Verkehrsteilnehmern den Wunsch, abzubiegen signalisieren soll. |
User Stories im Produkt Backlog Beispiel 1: Anforderungen für die Registrierung bei einer Software
Im Rahmen der Entwicklung einer Software für eine Lernplattform könnte eine User Story im Product Backlog etwa so aussehen:
„Ein neuer Kunde soll sich beim E-Learning-Portal registrieren können“
Dabei handelt es sich um eine recht komplexe User Story, die mit hoher Wahrscheinlichkeit sehr viel Kapazität benötigt.
Deshalb ist es sinnvoller, die Items und Aufgaben im Product Backlog noch weiter für die unterschiedlichen Teams aufzugliedern. Daraus könnten sich beispielsweise die folgenden Items ergeben:
- Rechtliche Anforderungen für das Formular abstimmen
- Anforderungen an das Formular mit Fachabteilungen abstimmen
- Formular für Registrierung nach den Anforderungen designen
- Pflichtfelder und Freifelder definieren
- Entwicklung einer Gültigkeitsprüfung für die einzelnen Formularfelder
Wichtig ist, die einzelnen Backlog Items im Produkt Backlog wieder aus der Sicht des Kunden zu formulieren. Also beispielsweise:
- Rechtssicherheit für den Kunden bei der Registrierung gewährleisten
- Einfache Registrierung durch entsprechendes Formular-Design sicherstellen
- …
User Stories im Produkt Backlog Beispiel 2: Unternehmens-Dashboard mit den wichtigsten Kennzahlen
Für das Management soll eine Software entwickelt werden, die schnell und einfach darüber informiert, wie es um die aktuelle Performance eines Unternehmens bestellt ist.
Die User Story im Produkt Backlog könnte aus Sicht der Manager beispielsweise folgendermaßen lauten:
„Als Manager möchte ich jederzeit Zugriff auf die wichtigsten Kennzahlen im Unternehmen haben, um daraus entsprechende Entscheidungen ableiten zu können.“
Das Entwicklerteam erhält damit eine grobe Ausrichtung über die Kernaufgabe. Diese muss in weiterer Folge jedoch noch in einzelne Anforderungen gebracht und so als Items im Produkt Backlog dargestellt werden, damit sich daraus Tasks für einen einzelnen Sprint im Scrum ergeben.
Analogien zu Backlog im traditionellen Projektmanagement
Im traditionellen Projektmanagement gibt es Spezifikationen. Dabei handelt es sich um die Definition eines Prozesses oder Produktes.
In einen Leistungsverzeichnis werden die einzelnen Leistungspositionen aus dem Projekt gelistet.
Das Lastenheft beschreibt den von den Stakeholdern vorgegebenen im Projekt zu erbringenden Leistungsumfang. Im Gegensatz dazu ist das Produkt Backlog aber nicht starr, sondern ändert sich bei jeder Version auf Basis der aktuellen Informationen.
Der Produkt Backlog im Scrum ersetzt beziehungsweise ergänzt diese Informationen aus den Werkzeugen des traditionellen Projektmanagements.
Was ist der Unterschied zwischen einem Produkt Backlog und einem Sprint Backlog?
Beim agilen Projektmanagement spricht das Entwicklerteam manchmal von einem Produkt Backlog und dann wieder von einem Sprint Backlog. In beiden Fällen handelt es sich um eine Liste mit Aufgaben, die vom Product Owner verwaltet werden. Die großen Unterschiede der beiden Arten bestehen jedoch vor allem im Umfang und den definierten Zeiträumen.
Sprint Backlog
Zu den Grundlagen von Scrum gehören die sogenannten Sprints. Bei dieser Methode geht es darum, vorab ausgewählte Aufgaben und Änderungen innerhalb eines bestimmten Zeitraumes abzuarbeiten. Basis dafür ist die Priorität der Aufgabe.
Es gibt also für jeden Sprint eine To-Do-Liste. Diese wird von den Scrum Teams als Sprint Backlog bezeichnet. Das Ziel jedes Sprints sollte dabei sein, ein funktionsfähiges Zwischenprodukt zu erstellen. Basis für die Auswahl der entsprechenden Items ist dabei der Produkt Backlog.
Produkt Backlog
Im Produkt Backlog werden alle Anforderungen an das fertige Produkt gesammelt. Bei Scrum werden diese als Produkt Backlog Einträge bzw. Produkt Backlog Items bezeichnet.
Es handelt sich also um eine Liste aus allen Schritten, die erledigt werden müssen, damit das gesamte Projekt abgeschlossen werden kann.
Zusammenfassend sind hier noch einmal die wesentlichen Unterschiede zusammengefasst:
| Produkt Backlog | Sprint Backlog |
|---|---|
| Besteht aus allen Aufgaben zur Umsetzung im Projekt | Beinhaltet nur einzelne Aufgaben aus dem Produkt Backlog |
| Wird unterteilt in Produkt Backlog Items | Wird unterteilt in Sprint Backlog Items |
| Ziel ist ein fertiges Produkt bzw. eine Dienstleistung | Ziel ist ein funktionsfähiges Zwischenprodukt bzw. Dienstleistung |
| Wird vom Produkt Owner verwaltet | Wird vom Sprint Team gemanagt |
Was gehört in ein Produkt Backlog?
Ein Produkt Backlog besteht aus einer Vielzahl unterschiedlicher Elemente, den sogenannten Items. Dazu zählen unter anderem:
- Features in der Produktentwicklung: Neue Funktionen und Verbesserungen
- Defekte: Arbeiten zur Fehlerbehebung
- Technische Themen wie beispielsweise Installation von Software
- Pflichtfelder und Freifelder definieren
- Wissenserwerb: Experimente und Erkenntnisse (zum Beispiel Teilnahme an einem Webinar)
Alle Produkt Backlog Items enthalten dabei zumindest die folgenden Attribute der Anforderung:
- Beschreibung
- Priorität
- Aufwandsschätzung
- Nutzen (für Kunden und andere Stakeholder)
Produkt Owner & Co.: Die unterschiedlichen Rollen beim Backlog?
Die Qualität beim Produkt Backlog ist stark von den beteiligten Personen abhängig. Jedes Mitglied im Scrum Team hat dabei unterschiedliche Aufgaben zu erfüllen, damit der Backlog stets aktuell bleibt und während des gesamten Projektverlaufs als Grundlage für die Umsetzung dienen kann.
Der Produkt Owner managt den Backlog
Der Produkt Owner trägt die volle Verantwortung für die Qualität des Backlogs. Seine Aufgabe ist es, die Einträge im Produkt Backlog klar zu formulieren und somit Klarheit für das Entwicklungsteam zu schaffen.
Darüber hinaus ist er auch dafür verantwortlich, dass der Produkt Backlog für das gesamte Entwicklerteam transparent und sichtbar ist. Jeder im Scrum Team sollte wissen, woran er in der nächsten Zukunft arbeiten wird, damit er dafür auch die entsprechende Kapazität einplanen kann.
Das Entwicklungsteam setzt den Backlog um
Für das Entwicklerteam stellt der Produkt Backlog die Basis ihrer Projektarbeit dar.
Im Rahmen eines Sprints werden aus dem Produkt Backlog die Items für den nächsten Sprint Backlog definiert und in einem Zeitraum von etwa ein bis vier Wochen selbstständig umgesetzt und anschließend im Rahmen einer Sprint Review vorgestellt.
Der Scrum Master schafft Klarheit
Der Scrum Master hilft dem Produkt Owner dabei, den Product Backlog bestmöglich einzusetzen. Er unterstützt ihn bei der Produktplanung und bei der Definition von klar verständlichen Zielen.
Dem Entwicklungsteam hilft der Scrum Master dabei, die Items innerhalb eines Sprint Backlogs selbstständig umzusetzen. Seine Priorität dabei ist es, die Selbstorganisation und die funktionsübergreifende Arbeit innerhalb des Teams weiterzuentwickeln.
Welche Software ist für einen Produkt Backlog empfehlenswert?
Grundsätzlich kann ein Produkt Backlog in einer einfachen Excel-Tabelle verwaltet werden. Darüber hinaus gibt es jedoch auch die Möglichkeit zur Verwendung spezieller Software.
Welche dabei genau zum Einsatz kommen sollte, ist vor allem vom
- Umfang des Backlogs,
- den erforderlichen Funktionen,
- dem vorhandenen Projektbudget sowie
- den persönlichen Vorlieben abhängig.
Bei cloudbasierten Tools sollte jedoch besonderes Augenmerk auf die Datensicherheit gelegt werden. Vor allem, wenn im Produkt Backlog auch vertrauliche Informationen enthalten sind, die nicht für das Auge von Mitbewerbern bestimmt sind.