Ideen für Backlogs

Zeig mir dein Backlog und wir versuchen euch zu sagen, wo eure Herausforderungen liegen. Das geht nicht immer, aber sehr oft. Mit meinem Kollegen Lino Otolski bin ich gerade zusammen für einen Kunden im Einsatz. Dabei hat es sich ergeben, dass wir uns beide bei einem Kaffee zum Thema Backlog unterhalten haben. Uns haben die Inhalte des Gesprächs so gut gefallen, dass wir diese an euch weitergeben wollten. Wir hoffen, dass dieser Artikel euch inspiriert, mit Hilfe des Backlogs bessere Produkte zu entwickeln.

Michael: "Hi Lino, fangen wir doch ganz grundlegend an! Was ist in deinen Worten ein Backlog und warum sollte ein Produkt-Entwicklungsteam ein Product-Backlog (PBL) haben?"

Lino: "In einem PBL ist die Arbeit strukturiert und zugänglich abgelegt, die ein Team leistet, um seine Ziele zu erreichen und seiner Vision gerecht zu werden. Ein PBL sorgt für ein Alignment im Team und dient ebenso als Hilfestellung, Arbeit fokussiert und priorisiert nach Geschäftszielen (hoffentlich user-centric) zu leisten. Das PBL ist damit ein zentrales Artefakt agiler Produktentwicklung."

"Was ist in deinen Augen die größte Herausforderung in Bezug auf das PBL?"

Michael: "In vielen Teams ist das Backlog tatsächlich ein “BACKlog”. Es ist veraltet (Wie ein Blick zurück, statt in die Zukunft). Ein agiles Team lernt im Grunde jeden Tag etwas dazu. Das heißt, das Team muss lernen all diese kleinen Erkenntnisse auch im Backlog transparent zu machen."

"Lino wie löst du diese Herausforderung in deinen Teams? Ist es deiner Erfahrung nach "OK" Einträge auch einmal zu löschen?” 

Lino: "Aus meiner Sicht ist ein Backlog ein lebendes Artefakt. Somit sind Änderungen an diesem erwünscht und sogar notwendig. Die Kunst dabei ist es, den Detailgrad der Arbeitspakete entsprechend der Relevanz zu wählen. Man will im Grunde so viel Arbeit wie nötig in das Backlog stecken und so wenig wie möglich. Somit können wir agil bleiben mit möglichst wenig Risiko, viel Zeit in die Planung irrelevanter Aufgaben zu investieren. Regelmäßiges Aktualisieren entsprechend nach dem DEEP (detailed/estimated appropriately, emergent, prioritized as needed) Prinzip ist meiner Erfahrung nach sehr hilfreich. Oftmals wird das Backlog in regelmäßigen wiederkehrenden Terminen gepflegt (z.B. Refinement, Estimation oder andere)."

"Michael, ich habe in der Vergangenheit bei dir herausgehört, dass du damit ein wenig “Bauchschmerzen” hast. Warum ist das so?"

Michael: "Etablierte, feste Termine für die Entwicklung des PBL sind alleine kein Garant für Erfolg. Diese Termine können das Team auch unflexibel und damit ineffektiver machen. Ich mag nicht sagen, dass vor allem junge Teams nicht mit solchen Teilschritten arbeiten sollten, um stückweise zu lernen, ein besseres Backlog zu entwickeln. Es ist aber für mich definitiv nicht das Zielbild. Der Scrum Guide empfiehlt Refinement als kontinuierlichen Vorgang während des Sprints zu verstehen und z.B. bei einem zweiwöchigen Sprint ca. 6 Stunden aufzuwenden. Bei 10 Arbeitstagen sind das ca. 30 Minuten am Tag!"

"Lino was für Prinzipien können mir helfen, um in dieser Zeit ein gutes PBL zu bekommen?" 

Lino: "Das Prinzip DEEP hatte ich bereits erwähnt, welches sich auf den Detailgrad der Arbeitspakete bezieht. Eine andere Perspektive ist, effizient mit den PBI ‘s arbeiten zu können. Hier unterstützt das INVEST-Prinzip. In diesem Fall steht INVEST für Independent, Negotiable, Valuable, Estimable- Sized appropriately, Testable. Sprich ein PBI sollte INVESTed sein. Jedes dieser Worte beinhaltet eine Menge. Beispielsweise ist die Voraussetzung für “Testable” ein für jeden verständlich kommuniziertes Outcome, welches im Optimalfall nach den SMART-Kriterien definiert ist (Spezifisch, Messbar, Akzeptiert, Realistisch, Terminiert). Ganz schön viele Buzzwords – aber sie machen den Unterschied."

"Michael was denkst du ist neben diesen Prinzipien noch wichtig, damit ein gutes PBL entstehen kann?"

Michael: "Die Teams, in denen ich arbeite, hören von mir oft provokativ den Satz: “ein Produktbacklog ohne Produktvision ist nur ein Haufen Arbeit”. Wenn wir es mit einer Wanderung vergleichen: “Nur weil wir weit laufen, heißt das nicht, dass wir auch am Ziel ankommen! Deshalb braucht es in meinen Augen eine klare Vision in jedem Team. Für ein erfolgreiches Produkt müssen die einzelnen Vorgänge auch auf eine Vision einzahlen."

"Aber Lino apropos Vorgänge. Das Backlog ist die einzige Quelle von Arbeit. Morgens aufstehen, habe ich bisher aber nie reingeschrieben. Was kommt alles in ein Backlog Lino? Was hältst du von einer Faustregel, wie alles, was länger als 30 Minuten dauert?"

Lino: "Ich denke in ein PBL gehören alle Produktideen, die das Team umsetzen möchte, um das Produkt zu verbessern. Umgesetzt werden dann die wertvollsten. Der Rest wächst mit der Zeit aus dem PBL heraus. Pauschal zu sagen, dass kleine Aufgaben nicht in das PBL kommen, ist meiner Ansicht nach nicht passend. Wichtige Informationen könnten so verloren gehen. Aber es ist sicherlich sinnvoll, nicht 20 Minuten etwas zu dokumentieren, wenn die Umsetzung nur eine Minute dauert und die Relevanz für das Team oder das Produkt eher klein ist."

"Was funktioniert denn konkret in dem Team, indem du aktuell tätig bist, gut in Bezug auf die PBL-Pflege?" 

Michael: "Wir sind richtig schnell darin, neue und in meinen Augen gute Stories zu erstellen. Neue Informationen sammeln wir kurz zur Besprechung in Miro für unser Daily. Dort nimmt die Story dann jemand mit und bereitet sie für das Team vor. In einem gemeinsamen Termin mit den Stakeholdern sprechen wir dann noch einmal kurz drüber und dann landet sie meistens direkt im nächsten Sprint. Als Struktur hat sich das Job Story Template sehr bewährt. Wir schaffen gerade oft eine Zykluszeit von weniger als einer Woche. Das macht viel Spaß. Das klappt unter anderem so gut, weil sich jeder für das Backlog verantwortlich fühlt und auch merkt, wie gut es funktioniert, wenn das alle machen." 

"Was klappt bei dir gut Lino?"

Lino Antwort: "Bei uns funktioniert es gut, einen festen Blocker am Tag zu haben, den wir flexibel für die Aktivitäten nutzen können, die uns helfen keine Bottlenecks aufkommen zu lassen. Sprich plannings, task-breakdowns, estimations, knowledge-sharing usw.. Wir ziehen uns sozusagen die Arbeit immer dann, wenn wir wieder Kapazität haben. So aktualisieren wir kontinuierlich und bedarfsorientiert das PBL. Oftmals beobachten wir das von Teams gefordert wird, an vielen Themen gleichzeitig zu arbeiten." 

"Michael was ist schlecht daran und wie können Teams eine solche Situation auflösen?" 

Michael: "Es ist schlecht, weil es einfach ineffektiver ist, an vielen Dingen parallel zu arbeiten. Ein Team kann eine solche Situation auflösen, in dem es priorisiert. Oft gibt es dann auch verschiedene Stakeholder, für die einzelnen Themen. In einem gemeinsamen Termin sollte, eine Reihenfolge der Themen festgelegt werden. Roadmaps können hier bei der Visualisierung und Kommunikation helfen!"

Das waren kurze Gedanken von Lino Otolski und Michael Thiel zum Thema Backlog. Wir freuen uns auf Feedback oder eure Ideen zu dem Thema und hoffen, dass die ein oder andere Idee euch hilft bessere Produkte zu entwickeln. 

Viel Spaß beim Nachdenken, 

 Lino & Michi