Ihr Backlog platzt aus allen Nähten und Sie wissen nicht, wo Sie mit dem Ausmisten anfangen sollen? Daniel Westermayr stellt Ihnen fünf Techniken vor, mit denen Sie Ihr Backlog ganz einfach reduzieren.
Als Mitglied erhalten Sie die wichtigsten Thesen des Beitrags zusammengefasst im Management Summary!
Ihr Backlog platzt aus allen Nähten und Sie wissen nicht, wo Sie mit dem Ausmisten anfangen sollen? Daniel Westermayr stellt Ihnen fünf Techniken vor, mit denen Sie Ihr Backlog ganz einfach reduzieren.
Als Mitglied erhalten Sie die wichtigsten Thesen des Beitrags zusammengefasst im Management Summary!
Viele Unternehmen haben sich in den letzten Jahren auf eine Reise zu mehr Agilität begeben. Die Gründe dafür mögen individuell unterschiedlich sein. Eines haben sie jedoch gemein: den Wunsch nach mehr Performance, mehr Leistungsfähigkeit, mehr Ergebnis. Und verspricht nicht der Scrum-Gründer Jeff Sutherland selbst in seinem Buch, „die doppelte Arbeit in der halben Zeit" zu erledigen? (Sutherland, 2014)
Dennoch bleiben viele Scrum-Implementierungen hinter den Erwartungen zurück. Weder steigt die Leistung kontinuierlich an, noch wird in der Ende-zu-Ende Betrachtung ein Mehr an Kundenwert geliefert. Gerne werden fehlendes Mindset oder fehlende Unterstützung des Managements als Gründe dafür ausgemacht.
Ich möchte den Blick auf einen Bestandteil lenken, der selten in die Betrachtung einbezogen wird, den ich jedoch als wiederkehrendes Muster in problematischen Scrum-Ansätzen erkenne: das überladene Backlog.
Das Backlog ist möglicherweise das wichtigste Element in Scrum, bestimmt jedoch eins der bekanntesten. Teams mögen keinen Scrum Master haben oder auf die Scrum Events verzichten – ein Backlog haben sie aber ganz sicher. Der Scrum Guide beschreibt das (Product) Backlog als "eine emergente, geordnete Liste der Dinge, die zur Produktverbesserung benötigt werden. Es ist die einzige Quelle von Arbeit, die durch das Scrum Team erledigt wird."
Klingt eigentlich ganz trivial, oder?
Wie so oft, liegt der Teufel auch hier im Detail – besser gesagt in den beiden kleinen, oft übersehenen Wörtchen "geordnet" bzw. "emergent". Der Gedanke ist ja, dass diese Ordnung im Backlog zu jedem Zeitpunkt die aktuelle Reihenfolge der zu entwickelnden Elemente, also den aktuellen Stand des Wissens widerspiegelt.
Warum ist dieses Detail so wichtig? Weil wir uns die Frage stellen müssen, wie realistisch es ist, größere Mengen von Elementen regelmäßig zu ordnen und zu aktualisieren. Wie sehr können wir noch von emergent, also "unbeständig, veränderlich" sprechen, wenn Einträge in einem Backlog fixiert sind, sobald sie einmal Eingang darin gefunden haben?
Erster Monat kostenlos,
dann 24,95 € pro Monat
Know-how von über 1.000 Profis
Methoden für alle Aufgaben
Websessions mit Top-Expert:innen
23.04.2021
Hallo und herzlichen Dank fürs Lesen und "damit-Auseinandersetzen". Zuerst, ja gemeint ist das Product Backlog, also die Menge der in naher Zukunft zu erledigenden Aufgaben. Mir ging es dabei weniger um die Zahl an sich, sondern darum, eine fixe und messbare Grenze zu setzen, die mich als Product Owner sozusagen "zwingt" mich aktiv damit auseinanderzusetzen ob ich addieren/tauschen möchte oder eben nicht. Die Komplexität der einzelnen Elemente ist bei der Zahl an sich nach meiner Erfahrung nicht entscheidend. Komplexität/Umfang bestimmt lediglich, wie schnell ich Neues addieren kann. Ein Beispiel: wenn mein Backlog 40 große Elemente enthält, die lange Zeit benötigen zur Umsetzung werde ich langsamer addieren können (und bis dahin nur austauschen) - wenn die Elemente kleiner sind kann ich wiederum schneller addieren und nicht nur tauschen. Was die Frage nach Epic etc. betrifft -> das hängt stark davon ab, wie die Organisation/das Projekt diese verwendet und welchen Fokus sie setzen möchte. Mein Anspruch an Scrum ist, die Menge der gleichzeitig gestarteten Arbeit zu reduzieren um mehr Arbeit abzuschließen. D.h. es ist ein valider aber möglicherweise kontraintutiver Gedanke (der auch in die fixe Obergrenze einzahlt) nicht mit jedem größeren Thema (oder Epic) gleichzeitig zu beginnen. "Stop starting, start finishing".
Hilft das in erster Näherung? -> ich stelle fest dass sich manche Fragen besser in einem Gespräch als per Dokument/Kommentar klären lassen. Gerne auf mich zukommen für einen Dialog :)
07.05.2021
Hallo Herr Westermayr,
ich vermute mal, dass sie das Problem ansprechen, was man hat, wenn man ein Backlog erbt?
Ich habe auch mit Backlogs zu tun, die mehrerer hunderte Einträge haben. Und kann diese sehr gut planen.
Meines Erachtens kann man sowohl beim Aufbau eines eigenen Backlogs, also auch beim "Aufräumen" eines fremden immer sehr gut mit klassischen Produktmanagement-Methoden vorgehen. Einige wurden bereits im Kommentar genannt: EPICs o.ä.
M.E. helfen aber gänzlich andere Methoden den Überblick zu behalten. Am Ende können diese Strukturen dann auch in Form eines Backlogs abgebildet werden.
So möchte ich Impact Mapping und Story Mapping nennen, die hervorragend geeignet sind aus hunderten von User Stories eine saubere Roadmap zu basteln. Ebenso helfen einem Stacey und Kano dabei die Detailtiefe zu bestimmen, die im Moment dann auch dem Nutzwert entspricht. Es kann ja nicht das Ziel sein, alles en detail festzuhalten.
Siehe auch Von der Kunst, in Time & Budget den maximalen Nutzen zu schaffen https://www.projektmagazin.de/artikel/agile-festpreisprojekte-der-praxi…
Viele Grüße
Tassilo Kubitz
Maximal 40 Einträge
23.04.2021
Hallo, als Autor schreiben Sie: "Meiner Erfahrung nach sind in einem Backlog für eine laufende Produktentwicklung maximal 40 Einträge angemessen." Worauf bezieht sich diese Zahl, auf Epics, Features oder User Stories? Anders ausgedrückt: Können Sie bitte etwas zur Komplexität eines "Eintrags" sagen? Stimmt meine Annahme, dass Sie bei den 40 Einträgen vom Produkt Backlog, nicht dem Sprint Backlog sprechen?