Wieviele Backlogs habt Ihr?

Moin.

Über Backlogs gibt es erstaunlich viel zu sagen, auch wenn die Sache auf den ersten Blick ganz einfach aussieht. Es ist doch bloß eine Liste von Dingen, die zu tun sind, damit am Ende ein fertiges Produkt herauskommt. Irgendjemand ist dafür verantwortlich, dass die Tickets in der richtigen Reihenfolge in der Liste stehen und das war’s, oder?

Escape the Feature Factory: Stefan Mintert

Stefan Mintert arbeitet mit seinen Kunden daran, die Unternehmenskultur in der Softwareentwicklung zu verbessern. Das derzeit größte Potential sieht er im Leadership; unabhängig von einer Hierarchieebene. Die Aufgabe, dieses Potential zu heben, hat er sich nach einem beruflichen Weg mit einigen Kurswechseln gegeben. Ursprünglich aus der Informatik kommend, mit mehreren Jahren Consulting-Erfahrung, hatte er zunächst eine eigene Softwareentwicklungsfirma gegründet. Dabei stellte er fest, dass Führung gelernt sein will und gute Vorbilder selten sind. Es zeichnete sich ab, dass der größte Unterstützungsbedarf bei seinen Kunden in der Softwareentwicklung nicht im Produzieren von Code liegt, sondern in der Führung. So war es für ihn klar, wohin die Reise mit seiner Firma Kutura geht: Führung verbessern, damit die Menschen, die die Produkte entwickeln, sich selbst entwickeln und wachsen können. Für Heise schreibt Stefan als langjähriger, freier Mitarbeiter der iX seit 1994.

Oft beobachte ich Folgendes: Das Backlog enthält ein paar Hundert Tickets. Manche sind ein Jahr alt oder älter. Einige Tickets führen zur Entwicklung neuer Features; sie heißen manchmal Stories, User Stories, Anforderungen oder so ähnlich. Bug-Tickets gibt es natürlich auch und dann sind da noch Dinge, die vielleicht Technische Stories, Dev Stories oder so ähnlich heißen. Während die Feature-Wünsche und Anforderungen vom Product Owner oder den sogenannten Stakeholdern stammen, sind die Tickets der letztgenannten Art von den Entwicklern geschrieben.

Und nun stellt sich die Frage nach der Priorisierung. Wie man einige Hundert Tickets in eine sequenzielle Reihenfolge bringen soll, habe ich noch immer nicht verstanden. Aber selbst mit vergleichsweise "wenigen" Tickets, sagen wir mal 80, 90 oder 100, ist es keine leichte Aufgabe, Features/Anforderungen und technische Aspekte zu sortieren. Wenn der Product Owner ehemaliger Entwickler ist, kann es sein, dass er die technischen Tickets versteht; hoffentlich versteht er in diesem Fall das Business gut genug, um seine Arbeit gut zu machen. Und wenn er einen Business-Hintergrund hat, stellt sich die Frage, ob er die technischen Einträge im Backlog ausreichend einschätzen kann, um eine sinnvolle Reihenfolge sicherzustellen. So oder so ist das eine knifflige Aufgabe, die kaum von einer Person allein zu bewältigen ist.

Mein Vorschlag, um das Reihenfolgeproblem in den Griff zu bekommen: Man verwendet zwei Backlogs. Eines verantwortet der Product Owner (Product Backlog) und eines verantworten die Entwickler (Dev Backlog).

Ja, ja, ich weiß. Aus dogmatischer Sicht habe ich dann keine Single Source of Truth. Mich stört das nicht, weil die Backlogs in freier Wildbahn öfter Single Source of Chaos, statt Single Source of Truth sind.

Was bringen zwei getrennte Backlogs?

1. Das Product Backlog stellt ausschließlich die Business/Produkt-Sicht dar. Feature-Wünsche, User Stories, Anforderungen und Bugs gehören dazu. Es ist damit für jedermann verständlich, der/die das Business und das Produkt versteht.
2. Das Product Backlog ist damit unweigerlich kürzer. Eine Sortierung herzustellen, ist schon allein aufgrund einer kleineren Zahl von Einträgen leichter.
3. Alles, was die Entwickler für wichtig halten, steht im Dev Backlog. Es hat einen gleichberechtigten Stellenwert mit den Einträgen im Product Backlog; zumindest in der Theorie.
4. Über die tatsächliche Gleichberechtigung entscheidet das Tagesgeschäft. Wer bestimmt auf welche Weise, ob ein Ticket aus dem Product Backlog oder dem Dev Backlog gezogen wird? Nehmen wir an, dass es so eine Art “Sprint Planning” gibt. Hier sind die Produktziele, die der PO verantwortet, maßgeblich. Sie haben Einfluss auf die Sprintziele. Aber die Entscheidung, wie das Sprint Backlog gefüllt wird, kann nicht ohne die Entwickler gefällt werden.
   Mit nur einem Backlog ist unwahrscheinlich, dass man im Planning die Tickets einfach von oben nach unten betrachten kann. Mit zwei getrennten Backlogs geht das viel einfacher. Der PO kann seine Ideen der Sprintziele mit den oberen Tickets im Product Backlog verknüpfen. Die Entwickler bringen die oberen Tickets aus dem Dev Backlog in den Dialog ein.
   Vielleicht funktioniert es sogar, dass das Dev Backlog im Gespräch mit dem PO gar keine Rolle spielt. Das Planning mit dem Produkt im Fokus wird dadurch verschlankt, der PO entlastet. Die Entwickler ziehen eigenständig die erforderlichen Dev-Tickets in den Sprint. Dafür braucht es Vertrauen zwischen PO und Entwicklern. Wenn das nicht vorhanden ist, wird es aber in jedem Fall schwierig und ich habe noch ein Thema für einen Blogartikel.

Zum Abschluss möchte ich noch eine weitere Sichtweise einbringen: Die Autoren Craig Larman und Bas Vodde schreiben in ihrem Buch “Large Scale Scrum” (S.281) Folgendes zu Backlogs: "Das Product Backlog dient der Verwaltung von Dingen (items), während das Sprint Backlog dem Team hilft, sich selbst zu managen. [...] Verwendet nicht dasselbe Werkzeug für Product und Sprint Backlogs!"

Verschiedene Tools für die beiden Backlogs? In Teams, die zusammen an einem Ort arbeiten, habe ich das häufig gesehen: ein Ticketsystem für das Product Backlog, ein physisches Board für den Sprint. Im Falle von räumlich verteilten Teams habe ich noch nie gesehen, dass verschiedene Werkzeuge für Product und Sprint Backlog zum Einsatz kommen. Ich bin neugierig, ob das gut funktioniert. Wenn jemand diesbezügliche Erfahrung hat, freue ich mich über eine Beschreibung in einem Kommentar.

(rme)