Produkt-Backlog und Sprint-Backlog in Scrum

Die Scrum Methodik kann nicht ohne das Product Backlog und das Sprint Backlog verstanden werden, zwei der Artefakte, mit denen sich das Scrum Team organisiert, um die Arbeit durchzuführen und ein gutes Endergebnis zu erzielen.

Ein Teil des Erfolgs eines Scrum-Projekts hängt von der Gestaltung eines guten Product Backlogs und Sprint Backlogs ab. In diesem Artikel zeigen wir Ihnen, was diese Dokumente sind und welche Tricks es gibt, um sie zu erstellen und Erfolg zu haben.

Was ist ein Backlog?

Backlog‘ bedeutet im Englischen so viel wie ‚anstehend‘ oder ‚angesammelt‘. Im Kontext von agilen Methoden ist das Backlog, um den Scrum Guide zu zitieren, „eine entstehende, geordnete Liste dessen, was zur Verbesserung des Produkts benötigt wird. Es ist die einzige Quelle für die Arbeit des Scrum-Teams“.

Insbesondere in der Scrum-Methodik erfüllen das Product Backlog und das Sprint Backlog Funktionen, die sich auf die Aufgaben beziehen, die ausgeführt werden sollen, um ein Produkt oder eine Dienstleistung zu liefern, die Kunden und Märkte zufriedenstellt.

Produkt-Backlog

In Scrum ist das Product Backlog die Liste der anstehenden Aufgaben, die nach Priorität geordnet sind, um das endgültige Ergebnis zu erreichen. Das Scrum Team führt diese Aufgaben in Sprints aus, kumulativ und ergänzend zu den vorangegangenen Sprints.

Dank dieser Liste hat das Scrum Team einen Überblick über die zu erledigenden Aufgaben und die Fristen, um diese zu erreichen. Zu diesem Zweck wird das Product Backlog auf einem Dashboard grafisch dargestellt, das die laufenden Arbeiten und ihren Status anzeigt. Dieses Dashboard kann mit weiteren Kategorien angepasst werden, je nach den Bedürfnissen oder der Arbeitsweise des jeweiligen Teams.

Elemente des Product Backlog

Das Product Blacklog setzt sich aus verschiedenen Elementen zusammen, die die Liste der anstehenden Aufgaben bereichern: User Stories oder Benutzergeschichten, Technische Geschichten und Fehler oder Bugs.

Benutzergeschichten

Obwohl im Scrum Guide nicht aufgeführt, ist es üblich, User Stories als Funktionalitäten oder Aufgaben zu verwenden, die in einem Sprint zu erledigen sind. Wie der Name schon sagt, müssen sie aus der Sicht des Benutzers gesehen werden, d.h. wenn wir sie schreiben (und wir werden uns im Abschnitt „Wie man ein Product Backlog erstellt“ daran erinnern), müssen wir an die Bedürfnisse des Benutzers denken, die das endgültige Ergebnis abdecken soll: sein tägliches Leben erleichtern, seine Freizeit verbessern…

Mit diesem Ziel im Hinterkopf werden die Geschichten als Anforderungen geschrieben, die sie haben. Eine Aufgabe könnte zum Beispiel lauten: „Ich muss auf jeder Produktseite dieses E-Commerce-Unternehmens die verschiedenen Merkmale (Farben, Modelle, Größen) sehen können, um das Produkt zu kaufen, das am besten zu meinen Wünschen passt“.

Technische Geschichten

Technische Geschichten sind technische Erfordernisse für die Durchführung eines Projekts. Sie sind keine zu erledigenden Aufgaben, sondern Voraussetzungen für den Fortgang des Projekts. Sie haben keinen direkten Wert für den Benutzer, obwohl sie einen Wert für die Lösung oder das Produkt darstellen, und das Scrum-Team muss sie ausführen, damit der Benutzer das Endergebnis genießen kann.

Ein Beispiel:

• Erstellen der Produkt- oder Service-Architektur
• Lernen, wie man neue Software verwaltet, um eine Sprintaufgabe zu erfüllen
• Erstellen von Datenbankindizes, damit Abfragen schneller gehen

Fehler

Fehler oder Bugs sind Fehler, die während der Entwicklung des Scrum-Projekts entdeckt werden und die im Product Backlog detailliert vermerkt werden müssen.

Wie man ein Product Backlog erstellt

Aufgrund der Wichtigkeit dieses Dokuments ist es ideal, ein Produkt-Backlog zu erstellen und zu pflegen, das von jedem im Scrum-Team einfach zu verwenden und zu verwalten ist. Hier sind einige Tipps, wie man dies erreichen kann:

• Wie wir bereits gesagt haben, einfach schreiben und aus der Sicht des Benutzers
• Priorisierung und Aufteilung in erreichbare Aufgaben. Etwas Grundlegendes im Scrum Product Backlog ist es, die Aufgaben nach der Notwendigkeit zu ordnen, sie auszuführen. Diese Priorisierung kann sich im Laufe des Sprints ändern, da sich die Verpflichtungen ändern.

Durch das Arbeiten in Iterationen wird das Backlog in Zyklen (Sprints) abgearbeitet, die es dem Team ermöglichen, sich auf jede einzelne Aufgabe zu konzentrieren und die letzte Aufgabe nicht als etwas schwer zu Erreichendes zu betrachten.

• Nur wirklich notwendige Einträge hinzufügen. Wenn Sie eine Benutzergeschichte, eine technische Geschichte oder einen Fehler aufnehmen, fragen Sie sich immer, ob dies zur Erreichung des endgültigen Ergebnisses beiträgt. Im Laufe der Entwicklung des Projekts kann es auch vorkommen, dass einige Einträge entfernt werden.
• Sorgen Sie sich nicht um den Grad der Spezifizierung aller Aufgaben. Sie können die weniger dringenden skizzieren (die sich ändern können, wenn es an der Zeit ist, sie auszuführen) und tiefer in die vorrangigen einsteigen. Wenn die ersten Aufgaben auf der Liste nach oben rücken, können Sie dem Team näher erläutern, was mit ihnen zu tun ist.
• Erfassen Sie das technische Wissen, das die Teammitglieder während der Sprints erwerben, sowie die technischen Verbesserungen, die in den verschiedenen Phasen auf das Ergebnis angewendet werden.

Verfeinerung des Product Backlog

Die Verfeinerung des Product Backlogs ist laut dem Scrum 2020 Guide „das Aufbrechen und weitere Definieren von Elementen in kleinere, präzisere Elemente. Es ist eine fortlaufende Aktivität, um Details wie Beschreibung, Reihenfolge und Größe hinzuzufügen. Die Attribute variieren oft je nach Umfang der Arbeit“.

Refinement ist kein Ereignis an sich, sondern eine Verbesserung des Product Backlogs, wenn das Scrum-Team vorankommt und Details, Fehler oder Probleme entdeckt.

Refinement-Meetings werden dann abgehalten, wenn die Teams Lust und Zeit dazu haben. Dies ist auch der Zeitpunkt, um die Aufgaben neu zu priorisieren, falls erforderlich.

Sprint Backlog

Das Sprint Backlog ist eines der Artefakte von Scrum und wird während des Sprint Planning-Events erstellt. Es besteht aus einer Liste von Aufgaben, die vom Scrum Team beschlossen wurden, und ist ein Teil des Product Backlogs, das während des Sprints bearbeitet wird. Es wird verwendet, um das Increment zu erreichen, d.h. das Endziel eines jeden Sprints, das zu den vorhergehenden hinzugefügt wird und zu diesen passen muss. Im Daily Scrum (tägliches Meeting) überprüfen die Teammitglieder, ob sie auf dem richtigen Weg sind, dieses Sprint-Ziel zu erreichen.

Das Sprint Backlog kann sehr anschaulich mit einem Scrum Board oder Scrum Board dargestellt werden; diese können mit Whiteboards, einer Tabellenkalkulation oder einem der vorhandenen Teammanagement-Tools, wie Azure DevOps, Trello, Asana, Monday oder Jira.

Sobald diese virtuellen Dashboards erstellt sind, werden die Sprint-Tasks in Spalten oder Listen platziert, um die Entwicklung ihrer Entwicklung zu sehen. Ein Scrum-Dashboard könnte zum Beispiel drei Spalten mit Aufgaben enthalten, die mit „Ausstehend“, „In Bearbeitung“ und „Abgeschlossen“ überschrieben sind.

Dank dieses visuellen Rasters ist es einfacher, den Stand des Sprints zu überprüfen und mögliche Risiken für das Nichterreichen des Sprint-Ziels zu erkennen.