Das Product Backlog (agilecoach.de Ausbildungskanal)

Video Nr. 7 aus dem agilecoach.de Ausbildungskanal auf YouTube: “Das Product Backlog”.

In diesem Video gehe ich auf das Product Backlog ein. Was ist ein Product Backlog? Wie funktioniert es? Wer verwaltet es? Was steckt da alles drin? Wie wird es priorisiert und sortiert?

<< Hier geht’s zum Ausbildungskanal auf YouTube >>

Hier direkt das Video…

Vollständige Transkription des Videos:

Was ist ein Product Backlog? Was steckt da drin? Was gehört rein? Was gehört auf keinen Fall rein? Wer verwaltet es? Wem gehört’s? Was machen wir überhaupt damit? Und wozu ist das eigentlich gut? Das sind alles Fragen die erörtern wir in diesem Video.

Das Product Backlog in Scrum beinhaltet alle Ideen, Feature-Wünsche, Anforderungen, User Stories und alles weitere, was getan werden muss, um unser Produkt wirklich umsetzen zu können. Bei einem klassischen Lasten- oder Pflichtenheft haben wir immer das Problem, dass wir gar nicht so genau sagen können, wie die Umsetzungsreihenfolge der einzelnen Anforderungen eigentlich geschehen soll.

Bei einem Product Backlog haben den großen Vorteil, dass es eine sortierte und damit priorisierte Liste aller Anforderungen und Ideen ist. Das heißt, von oben im Backlog nach unten befinden sich alle Einträge nach ihrer Wichtigkeit sortiert. Diese Reihenfolge ergibt sich idealerweise aus einer Business Value-Betrachtung. Das heißt, wir überlegen uns bei allen Dingen, die gemacht werden sollen oder die gemacht

werden könnten, ob sie wirklich sinnvoll sind, um unsere Produktvision Realität werden zu lassen und ob sie helfen, dem Anwender einen Mehrwert zu liefern. Die Einträge im Backlog mit dem größten Business Value stehen also ganz oben in dieser Liste und die Einträge mit dem geringsten Business Value, die also am wenigsten Wert oder vielleicht gar keinen Wert für den Anwender oder für unser Unternehmen  erzeugen, die stehen ganz weit unten im Backlog.

Neben der Betrachtung von Business Value können unsere Backlog-Einträge genauso gut auch über Risikobewertungen oder Abhängigkeiten zu anderen Teams, Technologien oder Abteilungen entsprechend priorisiert werden. Die eindeutige Priorisierung im Backlog sorgt also dafür, dass die Verantwortlichen für die Inhalte dieses Backlogs viel mehr in die Pflicht genommen werden, sich darüber Gedanken zu machen: Was ist denn wirklich wichtig? Was sind vielleicht weniger wichtige

Anforderungen? Und nach was müssen wir diese Anforderungen an sich und in sich eigentlich miteinander bewerten?

Bei ganz vielen Kunden, wo ich Scrum einführe und ihnen helfe, ihre Produktentwicklung effizienter zu

gestalten, stosse ich oftmals auf Argumente wie ungefähr dieses:

»Oh ne, das geht bei uns nicht. Also unsere Abteilungsleiter die haben sich jetzt über Jahre daran gewöhnt, dass wir mit Prio 1-2-3 arbeiten. Und wenn da mal was wichtiger ist, dann können wir eine

Prio null machen oder 0 a. Das geht dann schon aber durchnummerieren können wir diese Anforderungen nicht alle.«

Teilweise geht die Argumentation auch in folgende Richtung:

»Jaaa, ja ich weiß schon, was Sie meinen, aber dann lassen Sie uns wenigstens also so die ersten 20, dass die gleich wichtig sind.«

Ganz viele Leute versuchen auch, die Ganz-oder-gar-nicht-Strategie zu fahren:

»Ja das ist doch totaler Blödsinn! Wie soll denn das funktionieren? Bei uns ist alles wichtig. Es gibt nichts,

was nicht wichtig ist. Also was heißt denn hier, mehr oder weniger priorisieren? Wir müssen sowieso alles machen was da drin steht.«

Die Einteilung der Projektanforderungen in Prio 1-2-3-Kategorien oder solche 80% Lösungen, dass sozusagen sowieso fast alles wichtig ist und gemacht werden muss, das sorgt dafür, dass die Projektbeteiligten sehr wenig Transparenz darüber haben, was sinnvollerweise als nächstes zu tun ist. Mit einem gut gepflegten Product Backlog existiert diese Symptomatik überhaupt gar nicht, so dass alle Beteiligten wirklich mit Schwung voll fokussiert an die wichtigen Anforderungen und deren Umsetzung rangehen können.

Eine weitere, wichtige Eigenschaft des Product Backlogs ist, dass das Product Backlog kein statisches, finales Dokument ist, was am Anfang einmal geschrieben wird. Es handelt sich vielmehr um ein dynamisches Dokument, welches im Projektverlauf mitlebt und entsprechend angepasst wird. Das macht sich auch wieder über die Reihenfolge im Product Backlog normalerweise bemerkbar. Das heißt, im oberen Drittel des Product Backlog befinden sich schon sehr gut bekannte, teilweise ausspezifizierte

Anforderungen und User Stories, mit denen eine Umsetzung jederzeit sofort durchgeführt werden kann. Im zweiten, mittleren Drittel finden sich grobere Ideen, wo wir aber noch nicht so genau wissen, was soll eigentlich gemacht werden und was ist wirklich die genaue Zielsetzung dahinter. Und im unteren Drittel des Backlogs befinden sich normalerweise Dinge, bei denen wir vielleicht manchmal nur ein Stichwort wissen oder eine ganz grobe Richtung, in die man vielleicht auch mal gehen könnte, wo aber überhaupt gar nicht klar ist, ob das jemals wirklich auch passieren wird.

Die Detaillierung der Einträge im Backlog passiert also parallel zur Umsetzung während des ganzen Projektverlaufs. Grobe und große Anforderungen werden dann unterteilt, werden in kleinere Einheiten

aufgesplittet, die dann wiederum mit Details angereichert werden, die geschätzt werden können und wo eine Umsetzungsstrategie vom team erarbeitet werden kann.

Wichtig ist dabei, dass alle Projektbeteiligten ein klares, gemeinsames Verständnis über die obersten Einträge des Backlogs haben. Neue Ideen und Feature-Wünsche und User Stories können grundsätzlich von allen am Projekt Beteiligten in das Product Backlog eingepflegt werden. Wir dürfen dabei aber nie vergessen, was eigentlich das Ziel eines Product Backlogs und dessen Inhalte ist. Das liegt nämlich darin, unsere Produktvision möglichst schnell Realität werden zu lassen. Das heißt also, die Abwägung der

einzelnen Einträge im Product Backlog sollte idealerweise anhand der Wichtigkeit für unsere Produktvision stattfinden.

Die Hoheit über das Product Backlog und damit auch die Hoheit über die Reihenfolge der einzelnen Einträge im Product Backlog hat der sogenannte Product Owner. Er ist verantwortlich für die Inhalte und deren Sortierung im Product Backlog. Auf die Rolle des Product Owners werde ich in einem weiteren Video nochmal getrennt im Detail eingehen.

Ein Tipp noch ganz zum Schluss: Achtet darauf, dass euer Product Backlog höchstens 120 bis 150 Einträge hat. Ansonsten besteht die Gefahr, dass euer Team und die Projektbeteiligten keinen Überblick mehr darüber haben, was eigentlich gemacht werden soll und wohin eigentlich die ganze Reise gehen soll.

Das wäre es für heute zum Thema Product Backlog. Wir sehen uns im nächsten Video. Bis dann, tschüss.

Im agilecoach.de Ausbildungskanal auf YouTube finden sich laufend neue Videos zu agilen Themen wie Scrum, Kanban, Lean, Lean Start-up und alle artverwandten Themen.

Ich freue mich über Eure Kommentare und vor allen Dingen über Eure Fragen, die ich in kommenden Videos beantworten kann. Schickt einfach eine Mail an marc.bless@agilecoach.de oder nutzt die Kommentarfunktion unter den Videos auf YouTube.