Folge 047 Backlog

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,


Janina & Henry


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:


Was bedeutet Agilität

Get shit done

Janinas PO

Was macht Deinen PO so besonders



Connecte dich gerne hier mit uns:


LinkedIn


Instagram


Facebook


Webseite


The post Folge 047 Backlog appeared first on Znipcast - für gute
Zusammenarbeit | Agile, Scrum, KanBan, Psychologie,
Teamentwicklung und NLP | Podcast der Znip Academy.