Der Zufluss von Arbeit im Rahmen eines Projekts kann aus verschiedenen Richtungen kommen. Dies birgt die Gefahr, dass man den Fokus verliert, noch bevor man aktiv wird. Um einen integrierten und wertvollen Zufluss zu realisieren, können Sie das Product Backlog als geeignetes Werkzeug einsetzen.
Das Product Backlog ist eine sich entwickelnde, nach Prioritäten geordnete Liste dessen, was für die Entwicklung des Produkts benötigt wird. Daher ist es sehr wichtig, dass das Product Backlog als einzige Informationsquelle für die Arbeit des Scrum Teams angesehen wird. Eine häufige Frage, die sich im Zusammenhang mit dem Product Backlog stellt, ist: Wer ist berechtigt, das Product Backlog zu füllen? Diese und weitere Fragen werden in diesem Blog beantwortet.
Verantwortung für das Füllen des Product Backlogs
Die Arbeitsaufgaben in einem Product Backlog zeigen, „was“ erreicht werden kann. Dies bietet einen Rahmen für das Scrum Team, sodass das Scrum Team diese Items dann selbständig in Aufgaben umsetzen kann (wie). Da es hier eine klare Trennlinie gibt (was vs. wie), ist es wichtig, getrennte Verantwortlichkeiten zu haben. Deshalb sagen wir, dass der Product Owner für das „Was“ und die Entwickler für das „Wie“ verantwortlich sind.
Der Product Owner spielt eine wichtige Rolle im Product Backlog Management. Dazu gehören:
- Entwicklung und Kommunikation des Produktziels
- Erstellen und Kommunizieren von Product Backlog Items
- Priorisierung der Product Backlog Items
- Sicherstellung, dass das Product Backlog kontinuierlich sichtbar, transparent und verständlich ist
Der Scrum Guide stellt klar, dass die oben genannten Verantwortlichkeiten dem Product Owner gehören, aber an andere delegiert werden können. Der Product Owner bleibt immer der Letztverantwortliche.
Wen beauftragen Sie mit dem Schreiben von Items?
Im Scrum Guide ist nicht ausdrücklich festgelegt, an wen Sie das Schreiben von Items auslagern können. Sie können hier also an jeden denken. Die häufigsten sind:
- Entwickler
- Kunden
- Management
- Externe Stakeholder (z. B. der Kunde, Vermittler, Behörden)
Einige Vorteile des Outsourcing
Die Auslagerung des Schreibens von Items und die Befüllung des Product Backlogs mit ihnen hat einige offensichtliche Vorteile:
- Dies spart Zeit, sodass der Product Owner seine Zeit für das Stakeholder Management und die kontinuierliche Informationsbeschaffung auf dem Markt verwenden kann.
- Sie erhöhen das Engagement und damit die Bereitschaft zur Leistung
- Sie schaffen frühzeitig Klarheit darüber, was getan werden muss
Einige Nachteile des Outsourcing
Die Auslagerung der Erstellung des Product Backlogs hat natürlich auch ihre Nachteile. Schließlich gibt es nicht ohne Grund eine klare Abgrenzung der Zuständigkeiten. Denken Sie also immer daran, dass Scrum nicht mehr in seiner vollen Form angewendet wird, sobald Sie es auslagern. Dies wird alle Konsequenzen haben, sodass die Auswirkungen nicht mehr auf die Scrum-Prinzipien zurückgeführt (erklärt) werden können. Nehmen wir zum Beispiel:
- Sobald man das „Was“ loslässt, verschwimmt der Rahmen. Sicherlich, wenn diese nicht qualitativ beschrieben sind. Dies kann weitreichende Folgen bei der Umsetzung haben, da Sie als Product Owner eine größere Chance haben, die Kontrolle auszuüben, und die Entwickler im „Wie“ stecken bleiben können. Nur mit den richtigen Rahmenbedingungen kann man Autonomie richtig fördern.
- Das Auslagern des Schreibens von Items und des Befüllens des Product Backlogs bedeutet nicht, dass Sie immer den größten Wert erhalten. Ein Product Owner kann die gesamte Arbeit aus der Helikopterperspektive überblicken und kann daher besser feststellen, ob ein Item einen Wert hat.
- Die Übergabe bedeutet auch, dass es einen Interessenkonflikt gibt, sodass es leichter ist, einen Push als einen Pull zu erzeugen.
Es ist also immer gut sich vor der Entscheidung, das Füllen des Product Backlogs auszulagern (was so plausibel erscheint), bewusst zu machen, dass auch die Ideen der Selbstorganisation (was vs. wie) gefährdet sein können. Wenn Sie dies anerkennen und anschließend gemeinsam festlegen, wie es funktionieren kann, ohne dass es negative Auswirkungen hat, können Sie es auf gute Weise gestalten. Auf der Grundlage dieses Rahmens kann sich das Scrum Team gegenseitig auf die Verantwortlichkeiten aufmerksam machen und die Interessen gut trennen.
