Das Product Backlog in Scrum stellt den "Rückstand" zum Produkt dar. Es ist eine sortierte Liste, die alles enthält was zum jetzigen Zeitpunkt über das Produkt bekannt ist.
Eine Kapazitätsplanung im Backlog hat dort nichts zu suchen und wird gerne von Projektleitern angewendet, um Teams und Aufwände zu kontrollieren. Schauen wir uns in diesem Artikel die Symptome und Ursachen an.
Das Backlog in Scrum
Wie immer lohnt sich zunächst ein Blick in den Scrum Guide bevor wir uns mit konkreten Fragestellungen befassen und tiefer einsteigen. Dort hat der Scrum Guide folgendes zum Product Backlog zu bieten:
Scrum Guide
The Product Backlog is an ordered list of everything that is known to be needed in the product. It is the single source of requirements for any changes to be made to the product. The Product Owner is responsible for the Product Backlog, including its content, availability, and ordering.
A Product Backlog is never complete. The earliest development of it lays out the initially known and best-understood requirements. The Product Backlog evolves as the product and the environment in which it will be used evolves. The Product Backlog is dynamic; it constantly changes to identify what the product needs to be appropriate, competitive, and useful. If a product exists, its Product Backlog also exists.
The Product Backlog lists all features, functions, requirements, enhancements, and fixes that constitute the changes to be made to the product in future releases. Product Backlog items have the attributes of a description, order, estimate, and value. Product Backlog items often include test descriptions that will prove its completeness when "Done".
Was das Product Backlog enthält
Wie du oben lesen kannst, gehört alles in das Product Backlog, was benötigt wird, um das Produkt zu entwickeln. Da steht nichts davon, dass wir Kapazitäten im Product Backlog planen sollen oder ähnliche Aktivitäten. Es sind Aufgaben, die für das Produkt anfallen. Dazu musst du zum einen natürlich ein gutes Verständnis über das Produkt haben (ein Produkt und ein Projekt sind zwei Dinge), zum anderen musst du auch verstanden haben, was iterative und inkrementelle Entwicklung bedeutet. Sonst setzt du lediglich phasenorientierte Pseudo Agilität um - kannst du natürlich machen, bringt dir nur wenig bis keine Vorteile für deine agile Entwicklung.
Was das Sprint Backlog enthält
Das Sprint Backlog ist etwas anders, als das Product Backlog. Klar wirst du sagen, beide haben ja auch unterschiedliche Namen. Viele Teams sind sich zwar den Namen bewusst, straucheln aber etwas beim Inhalt. Denn während ein Product Backlog klare Produktthemen - also Produkteigenschaften - besitzt, sind im Sprint Backlog sämtliche Arbeiten aufgeführt, die das Team zur Erfüllung der Product Backlog Items benötigt. Hier geht es also um das konkrete "wie mache ich das? Wie setze ich diese Produkteigenschaft um?"
BEISPIEL: PRODUCT BACKLOG
Einen Workshop durchzuführen kann demnach nicht in einem Product Backlog stehen, sich aber durchaus in einem Sprint Backlog wiederfinden.
Versetze dich dazu mal an das Ende des Sprints, zum Sprint Review. Im Inkrement einen Workshop vorzustellen und den Stakeholdern erlebbar machen zu lassen, ist nicht wirklich logisch. Die Produkteigenschaft, in die der Workshop eingezahlt hat, aber schon!
Kapazitätsplanung im Backlog
Lass uns doch gemeinsam einmal eine kleine Reise durch das Product Backlog machen. Ich nehme dich zu typischen Aussagen mit und wir reflektieren gemeinsam, okay? Also los zur Reise "Kapazitätsplanung im Backlog".
Wertorientierte vs. kapazitativer Planung
Scrum optimiert sich auf den für den Kunden zu liefernden Mehrwert. Das bedeutet, die Dinge (Produkteigenschaften), die dem Kunden sehr wichtig sind, stehen oben in einem Product Backlog. Das ist etwas anderes, als nach einem plangetriebenen Vorgehen vorzugehen, in dem wir alle zu liefernde Aufgaben in einen Plan auflisten würden und diese Einhaltung dann prüfen.
Kapazität
Kundenwert
Aussagen in Teams
Jetzt gibt es immer ein "aber". Und das ist oft gut, denn es zeigt schon mal eine gewisse Resonanz, die du aufgreifen kannst. Schauen wir uns auch hier mal zwei typische Aussagen an.
Das ist alles richtig, wir müssen aber die Personen auch auslasten, die nichts zum hohen Wert beitragen können. Sonst sitzen die rum und das ist nicht gut!
Müssen wir das? Warum denn? Das wäre für mich mal zunächst zu klären, Wahrscheinlich hat das etwas mit einem fehlenden Teamgedanken und anderen tayloristischen Grundgedanken zu tun.
Und sitzen Menschen wirklich rum? Wenn wir wertorientiert arbeiten, werden die Personen im Team eine Möglichkeit finden mitzuarbeiten. Auch das Verbreitern von Wissen ist in einem multidisziplinären Team wichtig. Die Mitarbeiter können auch Pair-Doing machen und sich bei den Experten etwas abschauen.
Wir müssen alle Aufwände in das Product Backlog schreiben, damit mein Chef / die Organisation sieht, dass wir etwas tun.
Das ist echt eine spannende Aussage, denn es fehlt das grundlegende Verständnis von dem, was in einem Product Backlog steht. Sich der Lösung zu nähern, kann nur im Gespräch mit dem Chef sein und die konkreten Produkte und Teamschnitte zu überprüfen. Wenn Arbeitszeiten aufgeschrieben werden sollen, ist das prinzipiell nichts schlimmes, nur in einem Product Backlog hat das nichts zu suchen!
Und wo schreibe ich dann meine Aufwände hin?
Die Frage kannst du dir selbst beantworten und diverse Möglichkeiten sind denkbar. Meistens liegt die Kapazitätsplanung im Backlog daran, dass Tools eingesetzt werden, die nun einfach alles abhandeln sollen: Aufgaben, Zeiterfassung, Einsatzplanung und vieles mehr. Nicht selten kommt Jira zum Einsatz und ohne groß nachzudenken, wird dann wild der alte Arbeitsstil auf die neue Welt übertragen. Es muss nicht verkehrt sein, seine Arbeit zu dokumentieren. Nein, das wird gesetzlich sogar gefordert und die kreativsten Lösungen existieren, damit umzugehen. Nur ich darf das eine nicht mit dem anderen verwechseln, sonst kommen die komisches Situatonen heraus, die dich nur bremsen.
Wie ist eigentlich mein Produkt definiert?
Weite andere Möglichkeiten der Kapazitätsplanung im Backlog: Wenn das Produkt nicht klar definiert ist, Mitarbeiter in vielen Projekten und an den unterschiedlichsen Produkten arbeiten, dann will natürlich irgendwann, irgendwer wissen, woran arbeiten meine Mitarbeiter eigentlich?
Produkt- und Teamschnitt überprüfen
Kapazitätsplanung im Backlog hat häufig die Ursache in dem falschen Produktschnitt und / oder einer falschen Teamzusammensetzung.
Wie steht es mit dem Vertrauen?
Ein Klassiker ist fehlendes Vertrauen. Wenn jemand einem anderen nicht traut, was er in seiner Zeit macht, dann lässt man es ihn eben aufschreiben. Wo? Na wir haben doch das Product Backlog! Und sofort hast du eine Kapazitätsplanung im Backlog.
Vertrauen entsteht oft dadurch, dass geleifert wird und das zur richtigen Zeit. Wichtig ist aber auch, dass Nähe einen entscheidenen Faktor zum Vertrauen beisteuert. Wer in einer Orgaisation weit weg von den Teams und den Produkten ist, nur Verwaltung übernimmt und nicht nah am Produkt ist, sieht auch nicht, wie es Wert erzeugt. So entsteht oft der Wunsch etwas durch Zeiten und Kapazitäten messen zu wollen.
Und was kann ich tun?
Wie beschrieben können die Ursachen sehr unterschiedllich sein, warum eine Kapazitätsplanung im Backlog gewünscht ist. Ich kann dir nur empfehlen, dieser Ursache auf den Grund zu gehen. Zusammenfassend hier einige mögliche Ansatzpunkte:
Die unterschiedlichsten Gründe existieren. Ebenso sehen die Maßnahmen gegen die Kapazitätsplanung im Backlog aus. Ich bin mir sicher, wenn sich so etwas bei dir auch abspielt, dann findest du oben den ein oder anderen Hinweis dazu. Ich freue mich auch über deine Erfahrung in den Kommentaren!
