Backlog
Heute ges es um das Backlog, welches wir sicherlich in der ein oder anderen Folge schon erwähnt haben. Es ist so wichtig, da wir genau damit anfangen, wenn wir ein Projekt agilisieren.
Ein Backlog ist ähnlich einem Lastenheft und eine Sammlung von Aufgaben, die heute bekannt sind. Also eine Liste mit allen Dingen, die getan werden müssen um ein Produkt oder eine Dienstleistung zur Kundenzufriedenheit fertig zu bekommen. Es handelt sich also um eine umfassende Produktbeschreibung in allen Eigenschaften und Einzelheiten.
Wichtig dabei: Es ist nicht vollständig, sondern es sind alle Eigenschaften, die ich aktuell weiß. Riesen Unterschied zum Lastenheft ist, dass wir auch mit einem unvollständigen Backlog beginnen. Denn wir wissen, dass es wahrscheinlich nie vollständig ist und sich auf dem Weg noch verändert. Bei einem Lastenheft würden wir vor der Entwicklung so viel Zeit in das Lastenheft stecken, bis es perfekt ist. Wahrscheinlich würden wir ein paar Dinge, die in das Lastenheft müssten, dabei übersehen.
Es ist wirklich schön, dass jede Idee, egal wie spezifisch sie ist, erst einmal ins Backlog geschrieben werden kann. Dies entlastet alle Seiten, sorgt dafür, dass sie nicht verloren geht und kürzt oft auch Diskussionen ab. Vor allem bei Themen die gerade noch nicht dran sind, denn ich kann sie ja im Backlog parken.
Lastenheft
Das bedeutet, für egal welches Thema du mit Deinem Team bearbeiten möchtet, ihr schreibt erst einmal alle Ideen und Anforderungen in das Backlog. Dieses ist eine Liste. Das können Klebezettel, ein Stück Papier, Jira oder Excel sein. Natürlich gibt es noch deutlich mehr Tools. Überleg nicht lange welches Tool das Beste ist, sondern fang einfach an. Es ist viel schlimmer alle Ideen im Kopf zu jonglieren und ständig mit Kollegen über „man müsste“ zu sprechen, als es aufzuschreiben und dann zu machen oder eben nicht, wenn es am Ende der Liste steht.
Mit dem Backlog würde ich anfangen, weil hier eben alle Dinge, die zu tun sind, drin landen. Es bildet damit die Basis für alle weiteren Handlungen. Denn was bringt Dir ein Highperformance-Team, wenn es nicht weiß, was zu tun ist? Genauso ist das Backlog eine super Schnittstelle zur klassischen (PRINCE2) Welt. Denn wenn Du Dein Projekt klassisch machen musst oder mit einer klassisch organisierten Struktur zu tun hast, dann benötigen diese häufig ein Lastenheft. Fein, Dein Backlog ist automatisch auch Dein Lastenheft und umgekehrt. Du könntest also auch einfach ein fertiges Lastenheft aus Deinem Projektauftrag nehmen und als Backlog betrachten oder in Dein Backlog überführen.
Variabilität
Im Gegensatz zum Lastenheft bleibt das Backlog variabel. Es ist also nicht in Stein gemeißelt und wird sich wahrscheinlich während des Projektfortschritts / Produktentwicklung weiterentwickeln. Gleichzeitig werden Dinge, aus dem Backlog, die angefangen wurden, erst einmal zuende gebracht, bevor die neuen Aufgaben angefangen werden. Du erinnerst Dich an „get shit done„.
Dadurch, dass erst einmal alles in das Backlog geschrieben wird, was zur Erledigung (Done) nötig ist, gibt es unterschiedliche Detailtiefen der Einträge. Das ist okay, denn es wäre Verschwendung Dinge zu detaillieren, die jetzt noch gar nicht umgesetzt werden und sich vielleicht sogar auf dem Weg von allein erledigen oder doch gar nicht mehr begonnen werden.
Prioritäten
Es ändert sich auch die Reihenfolge Deiner Liste. Dafür ist der Product Owner zuständig. Er entscheidet welche Aufgaben die nächstwichtigen sind und kümmert sich auch darum diese vor der Umsetzung in eine adäquate Detailtiefe zu überführen. Auch hier gilt wieder, die Dinge, die angefangen wurden, werden erst zuende gebracht, dann folgen die nun neu hochpriorisierten.
Wichtig: Die Priorität ist immer eine eindeutige Liste in Reihung. Also es gibt genau eine Priorität 1, eine 2, eine 3, eine 4, etc. Niemals haben mehrere Anforderungen dieselbe Priorität. Ich glaube dies ist schon ein wahnsinniger Unterschied zu vielen klassisch geführten Projekten.
Dies erlaubt Dir auf dem Weg zu lernen und neue Spezifikationen zu Deinem Produkt hinzuzufügen.
Mitschrift
Wenn wir das Wort Backlog wortwörtlich nehmen, dann ist es eine Hintergrundmitschrift des Projektes. Wir können also jederzeit auch darüber ableiten, was in diesem Projekt passiert ist.
Achtung Änderung: Wenn sich ergibt, dass eine umgesetzte Anforderung doch nicht so toll war, dann gibt es einen neuen Backlogeintrag für die Anpassung. Im klassischen Anforderungsmanagement wäre es wohl so, dass die Ursprungsanforderung nun angepasst werden würde und diese dann wieder komplett in die Umsetzung ginge. Das machen wir nicht. Done ist Done und dann gibt es eine neue Anforderung, die nur die jeweilige Änderung enthält.
Die Arbeit des Product Owners
Zunächst ist das Backlog eine lose Sammlung von Ideen. Unsortiert, unstrukturiert und unspezifisch. Nun beginnt die eigentliche Arbeit des Product Owners. Er darf mit dem Team und seinen Stakeholdern das Backlog abstimmen, ordnen, sortieren und die nächstwichtigen Einträge entsprechend gut schneiden und beschreiben, so dass das Team sie leicht umsetzen kann.
Es muss dabei niemals das komplette Backlog betrachtet werden, sondern immer nur das Stück, welches als nächstes ansteht.
Nichtfunktionale Anforderungen und Qualität
Erst einmal, es gibt keine nichtfunktionalen Anforderungen. Jede Anforderung erfüllt eine Funktion. 😀
Solltest Du doch welche finden, lass es uns wissen. Diese und auch Qualitätsanforderungen stehen wie jede andere Anforderung auch im Backlog und werden entsprechend spezifiziert und abgearbeitet.
Schwelle niedrig halten
Es lohnt sich, wenn die Schwelle für neue Backlogeinträge sehr niedrig ist, damit wirklich jeder Anwender oder Stakeholder neue Einträge hinzufügen kann. Aus dem Changemanagement kenne ich es, dass die Hürden oft so hoch sind, dass viele gute Ideen gar nicht gehesen werden, da sie die Anwender nicht mitteilen. Halte also die Hürde möglichst niedrig.
Wenn das Backlog gut ist
Mit einem guten Backlog hat ein Projektleiter wirklich fast alles im Griff. Was hilft einem ein toller Budgetplan, wenn am Ende nicht das Richtige umgesetzt wird? Was hilft ein toller Terminplan? Das schöne ist, wenn das Backlog in Ordnung ist und das Team die richtigen Dinge tut, dann ergeben sich Terminpläne und Kostenschätzungen fast automatisch aus dem Backlog.
Dementsprechend, wenn Dein Backlog schlecht ist, dann Shit In, Shit Out.
Wenn Dein Backlog Gold ist, dann funktioniert wirklich das gesamte Projekt fast magisch. Es lohnt sich also darin etwas Energie zu stecken. 🙂
Auch unsere Redaktionsplan ist eine Art Backlog.
Get shit done,
Gefällt dir die Podcastfolge? Dann empfiehl sie gerne anderen weiter, z.B. indem du die Folge in deiner Story teilst. Wenn du magst verlinke @znip_academy_agile und wir teilen deinen Like mit unseren Hörern.
Du möchtest dich von uns in der Tiefe in eurem Veränderungsprozess begleiten lassen, eure größten Komplexitätsnester auflösen und die besten Teamtipps bekommen? Dann bewirb dich gerne für unser True Leader Coaching: https://forms.gle/6EteZLp8JhuTE2Dg9 – Durch deine Bewerbung hast du die Chance auf einen der nächsten freien Plätze.
In der Podcastfolge erwähnte Folgen zur Vertiefung:
Connecte dich gerne hier mit uns:
3 comments on “Folge 047 Backlog”