Es ist wieder Montag. Willkommen! Unser Thema für diese Woche:
Es gab Zeiten, da war es eine gute Idee, ein Backlog aufzubauen. Wie ist es heute?
Könntest du (dein Team) auch darauf verzichten? Welcher Fokus in diesem Zusammenhang wäre sinnvoll und könnte ein Backlog ersetzen?
… Honey I shrunk the backlog …
Ich freu mich sehr auf eure Beteiligung diese Woche!
Liebe Grüße! Dani
Mein erster Impuls ist, nicht auf das Backlog zu verzichten.
Die Frage ist, wie groß es sein soll oder muss.
Dutzende oder gar hunderte Einträge, die langsam sterben und vor sich hinschimmeln, braucht es nicht. Das ist in meinen Augen ein Zeichen von Big Design Up Front und komplett vorgeplanten Projekten für Feature Factories.
Eine gute Faustformel kann sein, genug “Material” für 2-3 Iterationen vorzuhalten. Das ermöglicht auch bessere Entscheidungen für die Devs.
Auch bei mir ist die erste Reaktion ein klares Nein. Denn die Anforderungen und Themen schwirren ja trotzdem herum, haben aber evtl. blockierende Abhängigkeiten oder die Kapazitäten reichen gerade nicht. Die Alternative ist häufig, dass sie per Excel o.ä. bei den Stakeholdern vorgehalten und dann in regelmäßigen Abständen per Mail angefragt werden.
Dem versuchen wir in unserem Team mit einem Global Backlog entgegenzuwirken, in das alle produktübergreifenden Anforderungen eingekippt werden können. Im ersten Schritt wird der Business value bewertet und, wenn er nicht ausreichend ist, das Thema nicht ins Backlog aufgenommen. Außerdem wird regelmäßig überprüft, ob die Relevanz noch gegeben ist. Klar entsteht so Aufwand, der aber meines Erachtens ohnehin anfällt: Entweder bei der individuellen Verwaltung oder beim Aufräumen des Backlogs.
Total spannend, danke euch! Ich denke, dass ein Backlog durchaus eine gut gemeinte Berechtigung hat. Ich fand den Ansatz von Allan in dem Impuls-Vortrag im vorletzten Meetup sehr gut, daher auch die aktuelle Frage der Woche. Um das nochmal nach ein paar Wochen “sacken lassen” wieder aufzugreifen. Seine Frage war unter anderem: was würdet ihr tun, wenn das Backlog plötzlich gelöscht werden würde? Und ich bin da bei ihm - wir (als ein Team gemeint) wüssten, was die richtigen und wichtigen Dinge sind, die es zu tun gibt. Und dass viele Items im Verlaufe der Zeit keine wirkliche Bedeutung mehr haben, da sie oftmals in der Zwischenzeit überholt worden sind und das Team eher belasten.
Mindestens würde ich sehr gründlich aufräumen und finde auch den Gedanken gut, dass es für die nächsten paar Sprints soweit gefüllt ist und darüber hinaus dann Raum ist. Die Ausgewogenheit ist wichtig, da dies immer auch einen guten Flow im Team und der Bearbeitung fördert, so meine Erfahrungen und aktuellen Gedanken dazu.
In meinem SAFe basierten Kontext würden wir ohne ein Jira-Backlog überflutet werden von E-Mails von Stakeholdern, die Wissen wollen, wie der Stand ist oder neue Ideen haben.
Unser Ansatz ist es, für ein PI Zyklus Ziele zu definieren und dann zu schauen, welche PBIs wir dafür benötigen. Auch ist das Backlog in unseren Fall für Abrechnungszwecke notwendig (Entwicklung macht ein externer Dienstleister).
Grundsätzlich versuchen wir neue Initiativen und Ideen erst in Confluence und/oder FigJam auszuarbeiten bevor sie in Tickets überführt werden.
Gerade in größeren Organisationen finde ich Backlogs als praktisch, um Informationen bereitzustellen ohne dass diese aktiv von mir bereitgestellt werden zu müssen.