Product Backlog. Strategischer Ausblick und Orientierung für das Scrum Team.

Vor Scrum waren wir es gewohnt, unsere Arbeit langfristig und detailliert zu planen. Das Resultat waren Arbeitspakete, die relativ isoliert voneinander betrachtet und nach längerer Zeit zusammen geführt wurden. Es war damit nicht möglich, iterativ vorzugehen, im Team früh zu lernen und nachzujustieren. Aber genau das ist es, was wir beim heutigen Komplexitätsgrad vieler Branchen benötigen. Die Basis für diese agile Arbeitsweise mit Scrum ist ein gutes Product Backlog. In Podcast-Folge #21  „Product Backlog“ erläutere ich, warum ein gutes Product Backlog essentiell für die Arbeit mit Scrum ist. Anhand einfacher “Faustregeln” verdeutliche ich, worauf es bei einem Product Backlog sowie dessen Pflege (Refinement) ankommt und wie man ein gutes Backlog sinnvoll nutzen und leben kann.

Das Product Backlog: Ein zentrales Element in Scrum

 

Vor einer agilen Arbeitsweise mit Scrum hatte man die Planung der Umsetzung strikt vorgeschaltet und dadurch Denken und Handeln voneinander getrennt. Wir waren es gewohnt, unsere Arbeit langfristig und detailliert zu planen. Das Resultat waren kleinteilige und spezialisierte Arbeitspakete, die relativ isoliert voneinander betrachtet wurden. Die Zusammenführung aller Ergebnisse erfolgte basierend auf eine anfangs vordefinierte Zeitleiste. Diese planungsgetriebene Denkweise hat jedoch entscheidende Nachteile: Es entsteht ein Druck, stets konform zum Plan zu sein. Das wiederum führt dazu, dass Probleme eher “umschifft” werden, als dass eine Auseinandersetzung damit erfolgt. Darüber hinaus verhindert die Aufteilung nach spezialisierten Gewerken die Möglichkeit, früh nachzujustieren. Sowohl Probleme als auch Kundenfeedback werden damit ans Ende des Projektes geschoben und sorgen nicht selten für ein “böses Erwachen”.  In vielen Branchen ist dieses Vorgehen gar nicht mehr möglich. Es müssen neue Wege gegangen werden die Denken und Handeln vereinen und den Kunden in den Entwicklungsprozess mit einbeziehen. Genau in diesen Bereichen kommst Scrum zu Einsatz (mehr über das Einsatzgebiet von Scrum findest du hier). Mit einer signifikant anderen Arbeitsweise ist es das Ziel mit Scrum, aus der gemeinsamen Verantwortung im Scrum Team und unter Einbeziehung der Kundensicht Sprint für Sprint Ergebnisse zu liefern und gemeinsam zu gestalten. Um dies zu erreichen, benötigt das Team gutes Backlog. Es stellt ein zentrales Element in Scrum dar und ist die Basis, gemeinsam als Team beste Ergebnisse zu liefern.

Das Product Backlog ist eine geordnete Liste, die alle Anforderungen an das Produkt umfasst, die zum Start der Entwicklung bekannt sind. Es werden alle Features, Funktionalitäten, Verbesserungen und Fehlerbehebungen aufgelistet und sichtbar gemacht. Während der ersten Entwicklungsschritte zeigt es die anfangs bekannten und am besten verstandenen Anforderungen auf und entwickelt sich mit dem Produkt und dessen Einsatz stets weiter. Ein Product Backlog ist demnach niemals wirklich vollständig.

Was zeichnet ein gutes Product Backlog aus?

 

Bei der effektiven Nutzung und Gestaltung des Backlogs geht es darum, ausreichend detailliert zu sein, um konkret in den Sprint starten zu können. Gleichzeitig ist es aber auch wichtig, eine gute Übersicht über das zu ermöglichen, was nach den unmittelbar bevorstehenden Sprints kommt. Dabei unterscheiden sich unmittelbar bevorstehende Items in ihrer Konkretheit von denjenigen Items, die weiter in der Zukunft liegen. Man könnte das Backlog auch mit einer Reise vergleichen: Unmittelbar bevorstehende Anforderungen, wie beispielsweise die konkrete Wegbeschreibung für den Hinweg, müssen bei Antritt bekannt sein. Über den Rückweg muss ich mir zu diesem Zeitpunkt in dieser Tiefe in der Regel noch keine Gedanken machen. Es genügt erstmal zu wissen, wann der Rückweg angetreten wird. Auch die Abfolge einzelner Schritte muss am Anfang der Reise feststehen. Muss ich zuerst nach A oder B um dann nach C zu gelangen? Ebenso soll auch das Product Backlog eine Abfolge bzw. eine Priorisierung verdeutlichen. 

Ein gutes Backlog muss demnach 

  • konkret und klar Aufschluss darüber geben, was als nächstes ansteht
  • einen groben Ausblick über zukünftige Schritte geben
  • eindeutig priorisiert sein

Durch diese strategische Übersicht ist es möglich, ein klares Sprint-Ziel festzulegen und konkret in den Sprint zu starten. Dennoch muss man sich bei der Arbeit mit dem Product Backlog stets vor Augen halten, dass niemals von Anfang an alle Informationen bekannt sein können. Entsprechend ist ein Backlog dynamisch und wird kontinuierlich gepflegt.

Vier „Faustregeln“ für ein gutes Backlog

1. Menge: Fünf bis zehn Items für den Sprint sind optimal.
Die Items sollten so eingeteilt werden, dass ca. fünf bis zehn in den Sprint einfließen können. Dadurch kann sichergestellt werden, dass weder zu wenig noch zuviel Items zur Bearbeitung vorliegen. Kümmert sich das Team um weniger als fünf Items, kann sich dies schnell negativ auf Auswertungen oder gar auf die Motivation der Teammitglieder auswirken. Werden beispielsweise nur zwei von vier Items nicht geschafft, gelten 50% des Sprints als nicht erledigt. Die Auswertung verschlechtert sich erheblich und die Motivation des Teams leidet. Darüber hinaus kann das Team bei weniger als fünf Items keine strategisch sinnvollen Entscheidungen bei der Item-Auswahl treffen. Entscheidet man sich hingegen dazu, mehr als zehn Items in den Sprint aufzunehmen, kann schnell die Übersicht verloren gehen. Fünf bis zehn Items stellen daher meiner Meinung nach die passende Menge dar

2. Auswahl: Die eineinhalb- bis zweifache Menge an Items bieten.
Um dem Team eine sinnvolle Auswahl der Items sowie einen Ausblick zu ermöglichen, sollte dem Team das eineinhalb- bis zweifache an Items vorliegen. Zusammenhänge und Synergien können so besser in bei der Auswahl der Items berücksichtigt werden.

3. Ausblick: Ein strategischer Ausblick schafft Orientierung.
Ein Backlog sollte dem Team auch immer einen strategischen Ausblick auf zukünftige Aktivitäten geben. Basierend auf diesen Informationen ist das Team in der Lage, sinnvolle Items zu wählen und Sprint-Ziele festzulegen.

4. Überblick: Die Arbeit mit max. 120 Items reduziert die Komplexität.
Ein Backlog sollte nicht mehr als 120 Items beinhalten. Konkret bedeutet das, dass es weder eine Ansammlungen von vielen sehr kleinteiligen Items sein sollte, noch dass große Items gemieden werden sollten. Es geht vielmehr darum, größere Items früh zu erkennen und im Verlauf schrittweise herunterzubrechen. Ebenso ist es möglich, Items die weiter in der Zukunft liegen, der Übersichtlichkeit zuliebe zu gruppieren.

Die Backlog Items

 

Es gibt in Scrum kein festgelegtes Format für Product Backlog-Einträge. Sie können auf unterschiedliche Weise dargestellt werden. Es können neben User Stories auch Use Cases, Bugs oder ganz eigene, “erfundene” Formate sein. Viele Teams arbeiten in der Praxis mit User Stories. Ein Format, das ich selbst gern nutze, da es mit seinen “Nutzer-Glücklichmach-Items” den Nutzer ins Zentrum der Entwicklung stellt und gleichzeitig eine sehr leichtgewichtige Möglichkeit darstellt, die Arbeit für alle Beteiligten sichtbar zu machen. Sie verdichten alles was notwendig ist, um in den Sprint zu starten. Gleichzeitig ermöglichen sie es durch ihren (noch) geringen technische Bezug, den Kunden von Anfang an in die Arbeit mit einzubeziehen – und genau darum geht es in Scrum. Mehr zum Thema User Stories gibt es hier.

 Sprint-Ziel und Product Backlog

 

Das Sprint-Ziel steht in unmittelbarem Zusammenhang mit den Backlog Items. Die Qualität des Backlogs hat demnach Einfluss auf die Formulierung des Sprint-Ziels. Geben Backlog Items einen guten strategischen Ausblick, lässt sich das Sprint-Ziel sehr klar daraus ableiten. Mehr zum Thema Sprint-Ziel gibt es hier.

Product Backlog Refinement

 

Das Backlog Refinement bedeutet die Pflege des Backlogs durch den Product Owner und das Entwicklungsteam. Früher wurde für das Refinement auch der Begriff Grooming verwendet. Dieser wurde aus dem American English übernommen. Er wurde jedoch abrupt wieder abgeschafft nachdem deutlich wurde, dass der Begriff im British English eine negative Bedeutung hat. In einigen Quellen wird er jedoch noch immer als Bezeichnung für die Backlog-Pflege (Backlog Refinement) verwendet.

 

Der Product Owner und sein Team.
Der Product Owner ist grundsätzlich für die Backlog-Pflege verantwortlich. Jedoch macht es keinen Sinn, dass dieser sich völlig isoliert darum kümmert. Ein guter Product Owner bindet sein Team frühzeitig und regelmäßig in die Pflege mit ein. Konkret bedeutet das, dass sie frühzeitig und gemeinsam Items besprechen. Dazu gehört auch, durch Schätzen der einzelnen Items den daraus entstehenden Dialog zu nutzen und durch effektives Splitting die Insights der Entwickler für die Backlog-Pflege nutzbar zu machen (mehr zum Thema Schätzen findest du hier.)

 

Backlog Refinement: Wann genau?
Das Backlog Refinement ist kein Scrum Ereignis, da dem Team völlig freigestellt wir, wann es diese Backlog-Pflege durchführt. Basierend auf der Annahmen, das Product Backlog könne vorausschauend bei der Planung des Sprints gepflegt werden, war diese ursprünglich Teil des Sprint Plannings. Neben der Festlegung des Sprint-Ziels und der Konkretisierung der Items für den Sprint wurden im Planning zusätzlich die Backlog Items gepflegt. Weil in den meisten Teams dieser Doppelfokus als zu störend wahrgenommen wurde, hat sich in der Praxis die Backlog-Pflege außerhalb des Sprint Plannings etabliert. Jedes Team muss dabei für sich selbst entscheiden, was am meisten Sinn macht. Es kann sich beispielsweise dazu entscheiden, das Backlog jeden Freitag- oder  Mittwochnachmittag zu pflegen, wenn kein Sprint-Wechsel stattfindet. Es kann sich aber auch dazu entscheiden, die Backlog-Pflege jeden Tag für 15 Minuten nach dem Daily zu erledigen. Das positive an dieser höheren Taktung ist, dass sie dem Product Owner dabei hilft, regelmäßig Meinungen vom Team abzuholen. Wofür du dich auch entscheidest: Wichtig dabei ist, dass es dem Team weiterhin möglich ist, sich auf den Sprint zu konzentrieren.

Ich hoffe, ich konnte mit meinen Tipps neue Impulse liefern, wie du dein Product Backlog gestalten und effektiv nutzen kannst. Hast du Fragen oder Anmerkungen? Ich freue mich immer über Feedback.

Zusammenfassung

Ein Backlog ist mehr als nur eine Ansammlung von Anforderungen. Es  ist unser strategischer Ausblick, mit dem wir als Scrum Team das Produkt gemeinsam ausgestalten. Anhand von wenigen Faustregeln hinsichtlich Menge, Auswahl, Ausblick und Überblick, kann die Backlog-Pflege effektiver gelebt werden. Es ist essentiell, dass der Product Owner das Team in die Backlog Pflege mit einbindet.

Übrigens: Solltest Du interessiert sein, dich im Rahmen eines Trainings noch einmal genauer mit den Scrum Events, Artefakten und Rollen theoretisch sowie praktisch auseinanderzusetzen, empfehle ich das Certified Scrum Master Training

 

Schreibe einen Kommentar