Mit dem Scrum Guide 2020 wurden den drei bekannten Artefakten drei Commitments hinzugefügt. Die Idee dahinter ist, den Artefakten mehr Qualität und Verbindlichkeit zu verleihen und für mehr Transparenz zu sorgen. Das Product Goal, über das wir hier schreiben, ist das Commitment für das Product Backlog.

Was hat es nun mit dem Product Goal als Commitment auf das Product Backlog auf sich?

Das Product Goal beschreibt das Ziel, das wir mit allen unseren Aktionen verfolgen, und stellt so den direkten Bezug zu allen Product Backlog Items im Product Backlog her. Denn ausschließlich alles, was nach unserem aktuellen Kenntnisstand zu tun ist, um das Product Goal zu erreichen, steht im Product Backlog. Das Product Backlog ist dadurch absolut auf das Product Goal fokussiert und gibt damit die notwendige Transparenz über den Plan zur Erreichung des Product Goals. Dabei beschreibt das Product Goal den Zustand, den das Produkt zukünftig haben soll, und sorgt damit bei allen Beteiligten für Klarheit.

Das Wort Goal (Ziel) beschreibt in der Regel den anzustrebenden Zustand mit messbaren Kriterien, anhand derer festgestellt werden kann, dass das Ziel erreicht wurde. Der Scrum Guide selbst geht auf die Formulierung des Product Goals nicht näher ein und erlaubt somit jedem Scrum Team, den für sich passendsten Einsatz in Formulierung, Detailierung und Umfang zu finden. Je nach Einsatz mag es für die Scrum Teams sinnvoll sein, eine detaillierte Beschreibung des Product Goals für die nächsten paar Monate zu erstellen oder aber eine kurze Beschreibung auf hoher Flugebene für die nächsten Jahre.

Egal, wie das Product Goal nun aussieht, den Ort, an dem es sich befindet, legt der Scrum Guide mit dem Product Backlog fest. Und daraus ergibt sich, dass das restliche Product Backlog mit allen seinen Product Backlog Items beschreibt, “was” alles zur Erreichung des Product Goals umzusetzen ist. Es kann allerdings sein, dass wir das Product Goal tatsächlich schon erreichen, ehe ausnahmelos alle weiteren Items umgesetzt sind. Sie würden zwar das Product Goal weiter ergänzen und somit auf das Product Goal einzahlen – sonst wären sie nicht im Product Backlog. Dennoch ist das Ziel vielleicht auch schon ohne deren Umsetzung erreicht. Als Vergleich zum besseren Verständnis kann hier das Sprint Goal und das Sprint Backlog dienen. Auch hier ist das Sprint Goal erreichbar, ohne dass zwangsläufig alles aus dem Sprint Backlog umgesetzt werden muss. Nur so ist es möglich, dass sich das Scrum Team in einem komplexen Umfeld auf das Product Goal committen kann und dabei die notwendige Flexibilität behält, um mit Unvorhersehbarem weiter umgehen zu können.

Das Scrum Team commitet sich darauf, das Product Goal zu erreichen, und kommt diesem von Sprint zu Sprint näher. Nach dem Erreichen des Product Goals kann sich das Scrum Team um das nächste Product Goal kümmern. Ob ein Produkt ein oder mehrere Product Goals hat, hängt von der Flughöhe des Product Goals ab, die für das Produkt und Scrum Team geeignet scheint.

Gibt es ein Product Goal, so enthält es in der Formulierung meist mehrere Zielsetzungen, die erreicht werden können. Eine Roadmap würde dann zum Beispiel den Weg beschreiben, um das Product Goal und die verschiedenen Objectives zu erreichen. Es kann aber auch sinnvoll sein, mehrere Product Goals zu formulieren und sich auf eines nach dem anderen zu fokussieren. Außerhalb von Scrum würde eine Roadmap z.B. dann die jeweiligen Product Goals als Etappenziele beschreiben. Hier gilt es zu beachten, dass sich laut Scrum Guide nur ein Product Goal zur gleichen Zeit im Product Backlog befinden darf und alles, was im Product Backlog steht, auf dieses Ziel einzahlen muss. Das bedeutet, dass das Scrum Team, sobald ein Product Goal erreicht oder endgültig aufgegeben wurde, das Product Backlog auf das nächste Product Goal ausrichtet. Generell ist noch anzumerken, dass sich auch das Product Goal zusammen mit dem Product Backlog entwickelt und es angebracht scheint, auch das Product Goal, wie alles in Scrum, einem kontinuierlichen Inspect & Adapt Prozess zu unterwerfen.

Wozu brauchen wir ein Product Goal?

Fokus, Transparenz und Verbindlichkeit sind die Treiber des Product Goals. Ein Product Goal gibt dem Scrum Team einen klaren Fokus. Alles, was das Scrum Team macht, kann und muss auf das Product Goal einzahlen. Das hilft ungemein, nur Wertvolles umzusetzen und die Time-to-Market zu verkürzen. Zusätzlich entsteht für alle Stakeholder eine absolute Transparenz darüber, worauf das Scrum Team hinarbeitet und welchen Mehrwert (Value) und welche Wirkung (Impact) es in der Umsetzung seiner Product Backlog Items innerhalb der eigenen Organisation und/oder außerhalb sieht und verbindlich erreichen möchte.

Wer ist verantwortlich für das Product Goal?

Der Product Owner – Er oder sie ist für die Wertmaximierung des Produktes verantwortlich. Sein bzw. ihr Plan zur Umsetzung der Wertmaximierung befindet sich im Product Backlog. Auch hierfür trägt der Product Owner die Verantwortung. Das Product Goal befindet sich im Product Backlog. Im Scrum Guide steht dazu. “Der Product Owner entwickelt und kommuniziert das Product Goal.” Aber auch hier gilt: Ein Product Owner ist gut beraten, das zusammen mit dem ganzen Scrum Team zu tun, um Ideen und Umsetzungsmöglichkeiten des Scrum Teams mit einfließen zu lassen.

Wie sieht die Arbeit mit dem Product Goal aus?

Für uns ist das Product Goal vergleichbar mit dem ersten Eintrag im Product Backlog. Auch hier haben wir meistens nicht mehr als eine sehr grobe Beschreibung dessen, was wir vorhaben und warum. “Als Bogenschütze benötige ich eine App, mit der ich meine Pfeile im Wald wiederfinden kann, um nicht ständig neue Pfeile kaufen zu müssen und um öfter schießen zu können.” Mit Hilfe von Refinements würden wir nun mit dem Scrum Team beginnen, dieses “grobe/große” Product Backlog Item zu verfeinern und zu zerlegen. Im Unterschied zu einem Product Backlog Item bleibt das Product Goal aber im Backlog erhalten und sollte jedem den Sinn und Zweck des Produkts mit seinen Zielen auf einen Blick zeigen. Ebenso würden wir das Product Goal in jedem Review zeigen und darüber sprechen, wie viel wir davon schon erreicht haben, möglichst mit Hilfe von messbaren Kriterien.

Zusammenfassend

Das Product Goal ist eine einfache, richtungsweisende Aussage, die dem Scrum Team und den Stakeholdern Kontext und Zweck für die Arbeit des Scrum Teams bietet. Und je nachdem, wie dieses Produktziel beschrieben, gemessen und aktualisiert wird, ändert sich dies mehr oder weniger. Um den vollen Nutzen des Product Goals zu entfalten, sollten wir es in unsere tägliche Arbeit integrieren, wie wir das mit jedem unserer Product Backlog Items machen und so den Fokus darauf richten, auf das gemeinsame Ziel des Produktes hinzuwirken.