Worum geht es?
Scrum ist ein leichtgewichtiges Rahmenwerk um komplexe Probleme zu lösen. Deshalb ist die Mechanik, wie im nächsten Bild dargestellt, relativ leicht zu verstehen:
Es ist der Job der Scrum Master:in das Scrum Rahmenwerk zum Leben zu bringen. Und dennoch ist das keine Garantie, daß das Produkt erfolgreich wird. Es ist die Aufgabe der Product Owner:in den Wert des Produkts zu maximieren. Es gibt viele Faktoren warum einige Produkte erfolgreicher sind als andere. Oft herrscht der Glaube, daß Entschlossenheit, Brillanz, das richtige Timing und großartige Ideen ausreichen um erfolgreich zu sein. In meiner Erfahrung kommt ein weiterer wichtiger Erfolgsfaktor dazu:
Ist das Scrum Team in der Lage Scrum gewinnbringend zu nutzen?
Bevor ich dazu 5 wichtige Elemente vorstelle, zunächst ein paar Grundlagen: 
Grundlegende Prinzipien von Scrum sind
- Empirie mit den 3 Säulen: Transparenz, Überprüfung, Anpassung (Transparency, Inspection, Adaptation)
- Selbstmanagement, d.h. das Team entscheidet intern wer was wann und wie macht.
Gleichzeitig gibt es diverse komplementäre Praktiken, die ausserhalb des Scrum Rahmenwerks liegen, weil sie kontextabhängig sind und je nachdem in welchem Kontext Scrum eingesetzt wird, sich stark voneinander unterschieden.
Fünf Elemente um Wertschöpfung zu maximieren
(1) Richtung vorgeben
Zunächst braucht die Product Owner:in ein Verständnis für das Problem potentieller Kunden und wie man mit einer Lösung für diese Kunden selber Geschäftsergebnisse generieren kann. Dazu reden Product Owner:innen mit ihren Kunden und beobachten potentielle Nutzer:innen bei der Arbeit.
Dieses Verständnis kann man mit Hilfe einer Produkt-Vision, Business Modell, oder Produkt-Ziel ausdrücken. Im Rahmen von Scrum braucht man mindestens ein strategisches Produkt-Ziel um zu starten und dann kann man anfangen den Product Backlog daraus abzuleiten. 
An dieser Stelle werde ich oft gefragt: Was ist der Unterschied zwischen Produkt Vision und Produkt-Ziel?
- Eine Produkt-Vision beschreibt den Zweck/Nutzen eines Produkts und die Ambitionen, die es anstrebt. Es ist der Nordstern des Produkts während des gesamten Lebenszyklus des Produkts. Wie im Bild dargestellt ist eine Produkt-Vision eine komplementäre Praxis und damit optional aus Sicht von Scrum.
- Ein Produkt-Ziel beschreibt einen zukünftigen Zustand des Produkts. Wie alle guten agilen Ziele ist es spezifisch und messbar. Damit gibt uns das Produkt-Ziel mehr Klarheit und Fokus als die Produkt-Vision. Gleichzeitig ist das Produkt-Ziel das Minimum, das ein Scrum Team braucht um mit Scrum zu starten. Sobald ein Scrum Team ein Produkt-Ziel erreicht oder verworfen hat, gehen sie das nächste Produkt-Ziel an.
Auch ohne eine klare Richtung werden die Mitarbeiter einen Weg finden beschäftigt zu sein, aber Erfolg wird dann zum reinen Zufall. Zudem wird es sehr schwierig alle Mitarbeiter in die gleiche Richtung zu bewegen und zu motivieren.
Hier kann die Product Owner:in glänzen, es ist ihre Aufgabe eine Richtung aktiv zu gestalten.
(2) Mindestens ein verwendbares Increment pro Sprint erstellen
Innerhalb von Sprints mit einer festen Länge von einem Monat oder weniger finden alle notwendigen Arbeiten statt um das Produkt-Ziel zu erreichen. Es ist sehr verführerisch nur technische Designs (z.B. Architekturdiagramme) oder Produkt-Designs (z.B. Mock-ups) während eines Sprints zu erstellen. Das Problem ist, daß solche Designs nicht valide sind bevor sie in einem verwendbaren Increment bewiesen worden. In komplexen Umgebungen erleben wir oft Überraschungen zur Machbarkeit und müssen erst herausfinden was machbar ist und was nicht. Deshalb wäre es eine Verschwendung, wenn wir im Sprint nur Designs erstellen und es würde uns die Möglichkeit rauben Feedback im Sprint Review einzuholen. Selbst wenn die Stakeholder:innen in der Lage wären Design Papiere zu lesen, nur Feedback für ein verwendbares Increment gibt tiefe Einsichten und erzeugt hilfreiche Diskussionen wie man weiter voran schreiten könnte. 
Eine typische Fehlwahrnehmung ist, daß viele glauben man könnte kein verwendbares Increment im ersten Sprint erstellen. Lasst mich das widerlegen. Ich habe mit einem Scrum Team an “Enterprise Warehouse Management” gearbeitet. Unser erstes Produkt-Ziel fokussierte auf „Inventory Management“ und selbstfahrende, computergesteuerte Gabelstapler. Im ersten Sprint haben wir ein sehr einfaches Feature gebaut, so daß ein Inventory Manager einen Gabelstapler ansteuern konnte und einige Basisdaten wie Typ des Gabelstaplers und aktuelle Position zurück bekam. Es war eine einfache Architektur nötig und minimales Produkt Design um dieses Feature zum Leben zu bringen. Das hat uns dann geholfen mit den Stakeholder:innen fundiert zu diskutieren was als Nächstes sinnvoll ist.
Natürlich entscheidet das gesamte Scrum Team im Sprint Planning was im Sprint erreicht werden soll. Hier kann die Product Owner:in bei der Formulierung des Sprint Goals über die Top-Einträge im Produkt Backlog gestalterischen Einfluss nehmen.
(3) Häufig Fakten aus produktiver Nutzung sammeln
Fakten in produktiver Umgebung sammeln ist der einzige Weg um herausfinden, ob ein verwendbares Increment wirklich Nutzen für den Kunden stiftet und um Annahmen zu validieren. Vielen Product Owner:innen ist leider oft nicht bewußt auf wie vielen Annahmen sie operieren. Je länger sie warten ein Release rauszubringen, desto mehr steigt das Risiko, daß sie in eine falsche Richtung investieren bis sie nicht mehr mit der Konkurrenz mithalten können. 
Häufige Release sind ein Wettbewerbsvorteil, die helfen können einen Vorsprung zu erzielen oder helfen können aufzuholen. Zugegeben häufig Release rausbringen zu können ist nicht einfach, und hängt von etlichen Faktoren ab, wie Kultur, Tools, Automatisierungsgrad und interne Prozesse. Eine Release-Entscheidung ist eine Business-Entscheidung und liegt bei der Product Owner:in. Es ist die Verantwortung des Scrum Teams die Voraussetzung für häufige Release zu schaffen. Diese Diskussion sollte im Scrum Team stattfinden, wobei die Product Owner:in dabei die Diskussion für ein Investment in verbesserte Prozesse aktiv mitgehalten kann. Gleichzeitig ist es wichtig Metriken zu wählen um dann faktenbasiert Entscheidungen treffen zu können. Hier hilft uns zum Beispiel das EBM Framework von scrum.org.
(4) Erlerntes zeitnah einarbeiten
Feedback und Daten aus produktiver Nutzung helfen uns zu lernen und den Kurs zu korrigieren. Im komplexen ist mehr unbekannt als bekannt, und daher bekommen wir ständig neue Erkenntnisse, neue Fakten, und Wissen. Diese arbeiten wir so schnell wie möglich in den Product Backlog ein um Transparenz zu schaffen und Verschwendung zu vermeiden. Auch eine Produkt-Vision wird angepasst sobald wir neue Erkenntnisse haben. Nichts ist in Stein gemeisselt. 
Refinement des Product Backlogs ist ein Vorgang, in dem die Product Owner:in und die Developer:innen Product-Backlog-Einträge weiter verfeinern um zu einem gemeinsamen vertieften Verständnis zu kommen. Techniken wie zum Beispiel User Story Mapping oder Impact Mapping helfen fokussiert über Wertschöpfung für Kunden und für unsere Organisation zu sprechen. Diese Techniken sind schnell, visuell und kollaborativ.
Refinement des Product Backlogs ist kontextabhängig, und jedes Scrum Team muss selber rausfinden bis zu welchem Detaillierungsgrad und wie oft sie es brauchen. Hier kommt Selbstmanagement des Scrum Teams zum Zuge, und das Scrum Team lernt es am Besten durch Experimentieren, Überprüfen und Anpassen.
(5) Die ganze Organisation respektiert die Entscheidungen der Product Owner:in
Wenn Entscheidungen der Product Owner:in von Stakeholder:innen überstimmt werden, dann kann das zu folgenden Problemen führen
- Die Product Owner:in kann ihrer Verantwortung den Wert des Produkts zu maximieren nicht gerecht werden
- Die Stakeholder:innen haben sehr wahrscheinlich nicht alle Fakten und Erkenntnisse. Das führt typischerweise zu suboptimalen Entscheidungen, politischen Spielen und Verzögerungen.
- Es kann zu Frustration im Scrum Team führen, weil es ihr Selbstmanagement hindert und sie demotiviert, insbesondere wenn diese über mehr Fakten und Erkenntnisse verfügen.
Deshalb ist es essenziell, daß die Entscheidungen der Product Owner:in von der ganzen Organisation respektiert werden. Leichter gesagt als getan. Eine Product Owner:in sollte die Sprache der Stakeholder:innen sprechen, sie im Entscheidungsprozess sinnvoll einbinden wie zum Bespiel beim Sprint Review und sich das Vertrauen der Stakeholder:innen erarbeiten. Vertrauen gewinnt eine Product Owner:in vor allem dadurch, daß sie den Stakeholder:innen die Transparenz gibt, die diese brauchen, und durch gute Resultate. 
TakeAways
Damit die Product Owner:in die Wertschöpfung für das Produkt mit Hilfe von Scrum maximieren kann, ist es wichtig, daß der empirische Prozess und Selbstmanagement des Scrum Teams gelebt wird. Das Scrum Team hat eine aktive Rolle die 5 genannten Elemente zum Leben zu bringen:
- Richtung vorgeben
- Mindestens ein verwendbares Increment pro Sprint erstellen
- Häufig Fakten aus produktiver Nutzung sammeln
- Erlerntes zeitnah einarbeiten
- Die ganze Organisation respektiert die Entscheidungen der Product Owner:in