Der Begriff Backlog ist ein fester Bestandteil der agilen Arbeitsweisen. Übersetzt bedeutet es so viel wie “Arbeitsrückstand” oder “Rückstand”. In der agilen Arbeit ist das Backlog eure Sammlung von Arbeitspaketen, die abgearbeitet werden müssen. Dort findet ihr zum Beispiel Anforderungen oder Aufgaben. Wir erklären euch, wofür ihr ein Backlog nutzen könnt, zu welcher Arbeitsweise es am besten passt und teilen mit euch Tipps für die Arbeit mit dem Backlog.
Arten von Backlogs
Ein Backlog findet ihr häufig bei der Arbeit mit der Scrum Methode, welche ursprünglich aus der Softwareentwicklung kommt. Aber auch in anderen agilen Arbeitsweisen, wie z.B. Kanban, gibt es ein Backlog, in dem die zu erledigenden Arbeitspakete gesammelt werden.
Das hilft euch insbesondere dabei, um im Team Transparenz über eure Aufgaben und Verantwortlichkeiten herzustellen. So könnt ihr jederzeit sehen, wer an welchem Thema arbeitet. Durch die Priorisierung eurer Aufgaben behaltet ihr außerdem euren Fokus und könnt euch besser organisieren.
Es gibt zwei Arten von Backlogs, die ihr nutzen könnt, um eure Arbeit zu strukturieren:
Product Backlog
Das Product Backlog ist ein wichtiger Bestandteil in der Arbeit mit Scrum. Dabei ist der Product Owner verantwortlich für das Managen des Product Backlogs. Er*Sie sammelt darin sämtliche Anforderungen eurer Kund*innen an euer Produkt oder eure Dienstleistung, die ihr entwickelt. Das können sein:
- Features – funktionale und nicht-funktionale Anforderungen für das Produkt
- Bugs – also Fehler, die behoben werden sollen
- Verbesserungen – Anpassungen des bestehenden Produktes, die es noch passender für die Kundenanforderungen machen
Der Product Owner formuliert die Anforderungen in User Stories so, dass sie für jeden verständlich sind und priorisiert sie. Im Sprint Planning stellt er*sie diese priorisierten User Stories dem Scrum Team vor, um ein gemeinsames Verständnis zu schaffen. Außerdem schätzen der Product Owner und das Team gemeinsam die Größe/den Aufwand. In den meisten Scrum Projekten werden die User Stories mit Punkten geschätzt, es gibt aber auch andere Möglichkeiten, die ihr nutzten könnt. Beispiele findet ihr in unserem Blog Artikel zum Thema Planning Poker.
Sprint Backlog
Das Sprint Backlog ist eure Planung der Arbeitspakete, also eurer User Stories, für den nächsten Sprint. Um die Inhalte des kommenden Sprints festzulegen, nutzt ihr im Sprint Planning euer Product Backlog als Grundlage. Als Team entscheidet ihr, wie viele und welche Dinge ihr aus dem Product Backlog im kommenden Sprint schafft und schiebt sie in euer Sprint Backlog. Da die User Stories bereits priorisiert und geschätzt sind, könnt ihr euch anhand eurer Punkte aus den vergangen Sprints auf eine Anzahl an User Stories einigen. Ihr könnt diese entweder einzelnen Personen aus dem Scrum Team zuordnen, oder die Verantwortlichkeit offen lassen und sie im Verlauf des Sprints verteilen.
Das Ziel eurer Planung im Sprint Backlog ist es ein Inkrement zu erzeugen. Ein Inkrement ist ein Zwischenergebnis, dass ihr euren Kund*innen im Review präsentieren könnt. Ein Inkrement kann z.B. ein neues Feature sein, zu dem euch eure Kund*innen Feedback geben können.
Unsere Tipps für die Arbeit im Backlog
Wir arbeiten bei nativDigital schon seit knapp 3 Jahren mit einem Backlog. Dabei haben wir vieles ausprobiert, verbessert und verworfen. Zu Beginn hat es uns geholfen, uns sehr stark an der Scrum Methode zu orientieren. So haben wir ein Gefühl für die Arbeitsweise entwickelt. Daher empfehlen wir auch euch zu Beginn relativ nah an dem Scrum Guide zu bleiben. Wir würden euch empfehlen, das mindestens 3 Iterationen auszuprobieren. Im Anschluss könnt ihr gemeinsam reflektieren, wie die Arbeitsweise für euch funktioniert hat und was ihr gerne anpassen würdet. Dafür hat uns eine gemeinsame Retrospektive sehr geholfen.
Folgende Dinge haben wir währenddessen und seither gelernt:
📲 Aufgeräumtes Backlog
Achtet darauf, dass euer Backlog gepflegt ist. Es ist nicht schlimm, wenn ihr User Stories verändert oder sogar löscht. Gerade bei langen Projekten empfehlen wir euch eine Ice Box, in der ihr aktuell nicht relevante User Stories parken könnt. So müsst ihr sie nicht gleich löschen, aber sie tragen auch nicht dazu bei, dass euer Backlog unübersichtlich ist. Euer Product Owner sollte ebenfalls regelmäßig die Priorisierung im Product Backlog überprüfen. So spart ihr euch Zeit im Sprint Planning und beim Füllen des Sprint Backlog.
👓 Klare User Stories
Formuliert eure User Stories einheitlich und so klar wie möglich. Wenn euer Sprint vier Wochen lang ist und eure User Stories nur aus halben Sätzen oder Stichpunkten besteht, kann es vorkommen, dass ihr im Verlauf der Zeit nicht mehr genau wisst, was ihr mit der User Story umsetzen wolltet.
📑 Realistische Schätzung
Nichts führt zu mehr Unzufriedenheit als eine unrealistische Schätzung im Sprint Planning. Versucht eure Arbeitsleistung im Team zu erfassen, so könnt ihr für die folgenden Sprints besser abschätzen, was ihr gemeinsam schafft. Denkt auch an Urlaube oder andere Projekte, die während der Sprints anstehen und so natürlich eure verfügbare Arbeitsleistung reduzieren.
✔️ Das richtige Tool
Es gibt eine Vielzahl an digitalen Tools, die ihr für eure Arbeit mit dem Backlog nutzen könnt. Einige, wie Jira oder Azure DevOps, sind sehr komplex und bieten viele Funktionalitäten, die insbesondere in komplexen Projekten zur Softwarenentwicklung hilfreich sind. Andere Tools, wie z.B. der Microsoft Planner, können ebenso als sehr einfache Variante eines Backlogs und Sprint Boards verwendet werden. Probiert auch hier aus, was für euch das richtige Tool mit der passenden Komplexität ist.
Habt ihr bereits Erfahrung mit der Arbeit im Backlog? Wir freuen uns auf einen Austausch mit euch und sind ganz neugierig auf eure Erfahrungen und Learnings.