Das Product Goal wurde 2020 formal in den Scrum Guide aufgenommen, und sein Verhältnis zu einer breiteren Produktvision ist genuin leicht zu verwischen, da beide auf einer Ebene oberhalb einzelner Sprint Goals operieren. Die Unterscheidung lohnt sich, präzise zu treffen, weil sie zu vermischen tendenziell Product Goals erzeugt, die entweder zu vage sind, um Sprint-Planung zu leiten, oder zu eng, um die mittelfristige Richtung zu bieten, für die das Konzept gedacht ist.
Wo es in der Hierarchie sitzt
Eine Produktvision ist die langfristige Ambition: wohin sich das Produkt letztlich entwickeln soll, potenziell Jahre entfernt. Ein Sprint Goal ist das unmittelbare, zweiwöchige (oder wie lang auch immer der Sprint dauert) Ziel. Das Product Goal sitzt dazwischen: ein mittelfristiges Ziel, typischerweise über mehrere Sprints hinweg, das dem Product Backlog echte Kohärenz und Richtung jenseits von "was gerade am dringendsten ist" gibt.
Ohne ein explizites Product Goal riskiert ein Product Backlog, zu einer locker geordneten Wunschliste zu werden, reaktiv Sprint für Sprint umpriorisiert, je nachdem, was gerade am dringendsten wirkt, ohne anhaltende Richtung, die die Arbeit eines Sprints mit der nächsten verbindet. Das Product Goal ist es, was einer Sprintfolge Kohärenz als zusammenhängendes Arbeitsvorhaben gibt, das auf etwas Konkretes hinarbeitet, statt einer Reihe unverbundener zweiwöchiger Anstrengungen.
Was ein Product Goal genuin nützlich macht, statt dekorativ
Ein funktionierendes Product Goal sollte konkret genug sein, dass sich mit angemessener Sicherheit sagen lässt, ob das Team es erreicht hat, sobald genug Sprints vergangen sind. "Das Produkt verbessern" scheitert an diesem Test vollständig: Es kann nie endgültig erreicht oder verfehlt werden, weil es nicht falsifizierbar ist. "Self-Service-Onboarding für neue Kund:innen mit weniger als 50 Mitarbeitenden ermöglichen, ohne Einbindung des Vertriebsteams" besteht diesen Test: Es gibt eine echte, überprüfbare Antwort darauf, ob das erreicht wurde.
Das Product Goal sollte auch innerhalb einer vernünftig absehbaren Anzahl von Sprints erreichbar sein, keine offene Ambition ohne natürlichen Endpunkt. Sobald ein Product Goal erreicht ist (oder genuin als unerreichbar bestimmt und aufgegeben wird), erwartet der Scrum Guide von der Product-Owner-Person, das nächste festzulegen, sodass der Backlog dauerhaft an einem konkreten, aktuellen Ziel ausgerichtet bleibt, statt ohne eines zu treiben.
Wie es im Alltag tatsächlich genutzt werden sollte
Sprint Planning sollte explizit auf das aktuelle Product Goal Bezug nehmen, wenn Sprint-Backlog-Elemente ausgewählt werden: Bringt die Arbeit dieses Sprints das Product Goal bedeutsam voran, oder ist sie davon losgelöst? Ein Team, das diese Frage für seine aktuelle Sprint-Arbeit nicht beantworten kann, hat entweder in der Praxis sein Product Goal aus den Augen verloren, oder hat ein Product Goal, das zu vage ist, um diese Art von Entscheidung tatsächlich zu leiten, und beide Probleme lohnt es sich, direkt sichtbar zu machen und zu adressieren, statt die Trennung still fortbestehen zu lassen.