Der Scrum-Reiseführer

4 Scrum Rollen – Die Idealbesetzung eines Scrum Teams

Unsere Reise in Scrum ist weniger auf den Individualtouristen ausgerichtet, sondern erlangt seine volle Pracht erst in einer Gruppe, die zu einem echten Team werden soll. Lernen Sie daher die Wege kennen, die auch abseits grauer Theorie einen perfekten Blick auf das Wesentliche bei der Teamzusammensetzung geben.

4.1 Passende Rollenbesetzung als Erfolgsschlüssel

Wie in jedem Team ist die passende Rollenbesetzung wichtig. Eine Reisegruppe zu den Pyramiden Südamerikas hat viel mehr Spaß, wenn ein kenntnisreicher Reiseführer dabei ist. Eine Fußballmannschaft ohne Torwart dürfte es schwer haben, Spiele zu gewinnen. Und auch ein American Football Team dürfte vor großen Herausforderungen stehen, ohne Quarterback im Super Bowl zu brillieren. Auch Scrum „benötigt“ bestimmte Rollen, damit es in der Praxis gut funktionieren kann.

Scrum macht es sich dabei sehr einfach, denn es gibt nur drei RollenScrum Rollen: Den Product Owner, den Scrum Master und das Entwicklungsteam. Wie die Rollenbezeichnungen schon andeuten, sind der Product Owner und der Scrum Master jeweils eine Person, das Entwicklungsteam jedoch eine Gruppe (siehe Abbildung 4).

Rollen in einem Scrum Team

Ein wesentlicher Aspekt von Scrum ist, dass es prinzipiell keine Hierarchien innerhalb des Teams gibt. Zwar hat jede Rolle die ihr zugeordneten Aufgaben, für die sie jeweils auch verantwortlich ist, aber ein hierarchisches Gefälle, in dem eine Person Anweisungen erteilt, die dann nur noch von anderen ohne Hinterfragen umgesetzt werden, wird klar vermieden. Diese Freiheit hat Vor- und Nachteile. Einerseits wird das Wissen aller Teammitglieder eingebracht, was in der aktuellen VUCA-Welt sinnvoll und notwendig ist – die notwendige Expertise für eine Produktentwicklung konzentriert sich auf Grund der Komplexität nicht in einem Individuum. Andererseits gibt es in der Praxis Momente, in denen der eine oder die andere sich ein bisschen „Basta“-Mentalität zurückwünscht, um längere Diskussionen abwürgen zu können. Und damit sind wir schon bei einem Kernthema von Scrum und von agilen Arbeitsmethoden im Allgemeinen: Kommunikation. Agile Arbeitsmethoden benötigen zwingend deutlich mehr Kommunikation und Abstimmung als Wasserfall-Methoden.

Wenn es keine Hierarchien innerhalb des Teams gibt, bedeutet das zusätzlich, dass das Team sich selbst organisieren muss. Selbstorganisierende Teams sind derzeit äußerst beliebt und finden als Schlagwort Eingang in viele Reden, Präsentationen und Veröffentlichungen (wie auch in diese). Aber was bedeutet Selbstorganisation überhaupt für ein Scrum Team? Wo liegen die Schwierigkeiten? Wie sieht das in der Praxis aus? Und kann das überhaupt funktionieren oder ist es eine Wunschvorstellung vom idealen, aber nie zu erreichenden Team Utopia? Die gute Nachricht ist, es kann funktionieren. Die Schlechte ist, es gestaltet sich oft schwieriger als es oft erwartet wird. Selbstorganisation bedeutet, dass das Scrum Team die Art und Weise der Zusammenarbeit innerhalb eines vorgegebenen Frameworks selbst definiert. Orchestriert wird das Ganze vom Scrum Master. In der Praxis kann dies eine Herausforderung für den Scrum Master sein. Dafür gibt es zwei Gründe: Erstens befürchten viele Manager einen gewissen Kontrollverlust, wenn sie dem Scrum Team nicht die Art und Weise der Zusammenarbeit vorgeben können. Zweitens fällt es manchen Mitarbeitern schwer, mit der neugewonnenen Freiheit umzugehen. Dies ist umso verständlicher, wenn man berücksichtigt, dass viele Unternehmen die letzten Jahre oder Jahrzehnte in einer Wasserfallwelt zuhause waren, in der sich eine Kultur der Compliance entwickelt hat. In einem solchen Umfeld wurde den Mitarbeitenden wenig Freiheit gegeben, um eigene Ideen voranzutreiben und auszuprobieren. Wird nun Selbstorganisation über Nacht per Dekret eingeführt, weil das Wort häufig in Verbindung mit agilen Arbeitsweisen fällt, kann dies schnell zu einer Überforderung der Mitarbeitenden führen, die noch kein Vertrauen in die neue Herangehensweise entwickeln konnten. Die Ursache beider Punkte liegt im agilen Mindset, das sich erst noch im gesamten Unternehmen ausbilden muss. Dieser Vorgang benötigt Zeit und sollte durch einen umfassenden Veränderungsprozess begleitet werden.

Scrum Teams sind crossfunktional, was bedeutet, dass innerhalb des Teams alle Fähigkeiten vorhanden sind, die für die Erreichung des Produktziels notwendig sind. Nehmen wir als Beispiel eine Webapplikation, die unter Verwendung von Wetter- und Verkehrsdaten die Besuchszahlen für einen Zoo vorhersagen will. Ein solches Scrum Team könnte aus einem Product Owner, einem Scrum Master und Entwicklern bestehen, die folgende Fähigkeiten bereithalten: UX/UI-Design, Frontend- und Backendentwickler, Testentwickler, Datenbankentwickler, Data Scientist.

Das obige Team würde aus circa sieben Mitgliedern bestehen (abhängig davon, ob bestimmt Fähigkeiten in einer Person vereint sind oder, ob bestimmte Kompetenzen mehrfach vorhanden sein müssen). Die Frage nach der Größe eines Scrum Teams wird vor dem Beginn des Projektes beantwortet. Folgende Faustregel kann dabei verwendet werden: Das Scrum Team sollte klein genug sein, um flexibel agieren zu können und den Kommunikationsaufwand nicht zu groß werden zu lassen. Gleichzeitig sollte es groß genug sein, um einen signifikanten Fortschritt zu erzielen. Typischerweise liegt die Zahl zwischen sieben und neun Teammitglieder. Kleine Teams sind meist produktiver und kommunizieren effizienter. Jeff Bezos hat bei Amazon die Zwei-Pizzen-Regel eingeführt, um die ideale Teamgröße für ein produktives Arbeiten zu bestimmen (siehe Abbildung 5).

Performance – Teamgröße

Sie besagt, dass an einem Meeting nur so viele Mitarbeiter teilnehmen dürfen, wie von zwei Pizzen satt werden. (Achtung, gemeint sind amerikanische Pizzen, die im Gegensatz zu europäischen Pizzen einen Durchmesser von 40 cm anstatt von 26 cm haben. Von einer amerikanischen Pizza werden vier Personen satt.) Die Anzahl an Teilnehmern ist demnach auf acht beschränkt. So willkürlich diese Zahl erscheinen mag, sie ist wissenschaftlich fundiert und wird auch von Bob Sutton in seinem Buch Scaling Up Excellence: Getting to More without Settling for Less bestätigt. Wird ein Team zu groß, sollte das Team in kleinere Einheiten zerteilt werden. Ab jetzt betreten wir den Bereich der Skalierung von agil, der wir uns später in einem separaten Kapitel widmen. So viel sei bereits an dieser Stelle gesagt: Wird das Thema Skalierung nicht umfänglich durchdacht, was in der Praxis häufiger vorkommt, kann dies mittel- und langfristig sowohl zu funktionalen als auch technischen Problemen führen, die nur mit einem enormen Zeit- und Kostenaufwand wieder beseitigt werden können.

Scrum Teams kümmern sich um alles Produktbezogene. Das umfasst unter anderem das Stakeholder Management, das Erfassen und die Verifikation von Anforderungen (in Form von Epics und User Stories), die Entwicklung eines wert- und sinnvollen Produktinkrements am Ende eines Sprints, den operativen Betrieb und was sonst noch alles anfallen könnte. In einem solchen Szenario kann es zu Situationen kommen, in denen die Teammitglieder eigenverantwortlich Entscheidungen im Sinne des Produktes treffen müssen. Um die Produktivität des Teams durch aufwendige Rücksprachen dazu nicht zu behindern, ist ein gewisser Spielraum förderlich, indem selbst Entscheidungen getroffen werden dürfen. Hierbei spricht man von Empowerment. Es ist ein wesentlicher Erfolgsfaktor von agilen Teams, wenngleich sich dieser Aspekt auf Grund der bereits oben genannten Herausforderungen als schwierig in der Praxis erweisen kann.

4.2 Entwickler als T-Shaped Professionals

Die Hauptaufgabe der Entwickler ist es, ein nutzbares Produktinkrement am Ende eines Sprints erzeugt zu haben. Wir werden in Kapitel 5.5 und 5.6 noch einmal intensiv auf diesen Punkt eingehen, da er ein essenzieller Bestandteil von Scrum ist und in der Praxis manches Mal falsch umgesetzt wird. Die Betonung liegt insbesondere auf nutzbares Produktinkrement, also etwas, was Fachabteilungen im operativen Geschäft verwenden können und das einen Nutzen, einen Mehrwert, bringt.

Die lediglich drei vorhandenen Rollen in Scrum erwecken den Eindruck, dass Vorgehensmodell sei einfach umzusetzen und strukturiert. In der praktischen Anwendung führt ebendiese Einfachheit jedoch gelegentlich zu Verwirrungen. Das Verständnis für das Konzept crossfunktionaler Teams ist deshalb umso wichtiger. Crossfunktional bedeutet, dass in einem Entwicklerteam alle notwendigen Kenntnisse, um ein Produktinkrement zu erzeugen, vorhanden sind. Zerlegen wir als Beispiel einen Softwareentwicklungsprozess in drei Schritte: Analyse, Programmierung, Testen. Ein Scrum Team würde mindestens diese drei Fähigkeiten abbilden müssen. Im Idealfall wird jeder Schritt von einem Experten begleitet, der über zusätzliches Know-how in den anderen Bereichen verfügt. Solche Teammitglieder bezeichnet man als T-Shaped ProfessionalsT-Shaped Professional (siehe Abbildung 6). Der große Vorteil besteht darin, dass T-Shaped Professionals Tiefenwissen (Expertenwissen) in einem Bereich besitzen und zeitgleich über ein Breitenwissen aus anderen Bereichen verfügt. Solche Mitarbeiter haben in der Regel einen scharfen Blick für das große Ganze und greifen die Gesamtzusammenhänge schnell; eine Fähigkeit, die besonders in dynamischen und agilen Arbeitsumgebungen von Vorteil ist.

T-Shaped Professionals

Um die oben beschriebene Hauptaufgabe, ein nutzbares Produktinkrement am Ende eines Sprints zu erzeugen, erreichen zu können, sind folgende Tätigkeiten ebenfalls in der Verantwortung des Entwicklerteams: Das Team erzeugt einen Plan für den Sprint, das sogenannte Sprint Backlog. Hierin werden alle Aufgaben, die innerhalb des Sprints erledigt werden sollen, transparent aufgelistet. Um jedoch eine zielgerichtete Erledigung der Aufgaben zu gewährleisten, ist es notwendig, Abhängigkeiten bereits im Vorfeld zu identifizieren und die Planung entsprechend anzupassen. Wird dieser Punkt nicht beachtet, könnten einzelne Aufgaben die Tätigkeiten anderer Teammitglieder blockieren und somit die Erreichung des Sprintziels gefährden. Das Entwicklerteam ist maßgeblich für die Qualität des Produktes zuständig. Hierbei ist vor allem die Definition of Done wichtig, die konkret definiert, wann eine bestimmte Aufgabe oder User Story fertiggestellt ist. Qualität sollte dabei bereits als integraler Bestandteil des Entwicklungsprozesses gesehen werden, um sie von vornherein in das Produkt zu integrieren und nicht erst anschließend in aufwendigen Testphasen zu ergänzen. Dieser Umgang mit Qualität ist eine Umsetzung des Andon Cords, dass bei Toyota Verwendung findet und zu einer enormen Steigerung der Qualität geführt hat. Das Andon Cords ist eine Leine, die jeder Mitarbeiter entlang der Produktionsstrecke ziehen kann – und damit die gesamte Produktion stoppt –, sobald ihnen Qualitätsmängel auffallen. Als Folge werden Probleme und Qualitätsmängel frühzeitig im Prozess erkannt und können kostengünstiger korrigiert werden, als wenn man diese nach der Produktion feststellt. Die tägliche Anpassung des Plans gehört deshalb zu den Aufgaben eines Entwicklerteams. Die Korrekturen finden im Rahmen der Daily Stand-ups statt. Sie dienen dazu, den Weg zum Sprintziel zu optimieren und somit das Ziel schneller, effizienter oder günstiger zu erreichen. Veränderungen, die keinen Einfluss auf die Erreichung des Sprintziels haben sind obsolet. Darüber hinaus trägt jedes Teammitglied die Verantwortung, sich selbst und die anderen immer wieder aufs Neue in die Pflicht zu nehmen, die vereinbarten Ergebnisse im Rahmen eines Sprints zu erreichen.

4.3 Scrum Master als Servant Leader

Die Rolle des Scrum MastersScrum Master ist entscheidend bei der Implementierung von Scrum in Unternehmen. Der Scrum Master übernimmt gleich mehrere Schlüsselaktivitäten, die maßgeblichen Einfluss auf eine erfolgreiche Einführung haben. Zusammengefasst kann die Rolle so definiert werden, dass der Scrum Master der Dienstleister im Scrum Team ist, denn seine Hauptaufgaben als Servant LeaderServant Leader, die wir uns im Nachgang näher anschauen werden, weisen einen gewissen Dienstleistungscharakter auf.

Der Scrum Master ist dafür zuständig, Scrum als Produktentwicklungsmethode in einem Unternehmen einzuführen und zu etablieren. Diese Aufgabe beinhaltet zu einem großen Teil Training- und Coachingaktivitäten, um das Team und die Organisation zuerst mit den üblichen Begrifflichkeiten und ihren jeweiligen Bedeutungen bekannt zu machen. Ein wesentlicher Aspekt für die erfolgreiche Einführung von Scrum ist, dass die Aufgabe des Scrum Masters die Teamgrenzen überschreitet. Erst wenn auch das Stakeholder-Umfeld mit Scrum verstanden hat, wie Scrum funktioniert und welche Anforderung auf die umstehenden Parteien außerhalb des Teams zukommen, hat Scrum eine Chance, erfolgreich zu sein. Es ist dabei in der Praxis nicht so wichtig – der eine oder die andere mag hier widersprechen –, dass Scrum eins-zu-eins wie im Scrum Guide beschrieben umgesetzt wird. Vielmehr ist es ausschlaggebend, dass der Scrum Master das Unternehmen mit agiler Denkweise, dem oft zitierten Agile Mindset, vertraut macht und dass eine Variante von Scrum gefunden wird, die zum Unternehmen passt und bestmögliche Erfolgsaussichten hat. Weiterhin hat der Scrum Master die Aufgabe, sich um die Effektivität des Scrum Teams zu kümmern und es dabei zu unterstützen, sich stetig zu verbessern. Dies kann auf vielfältige Weise geschehen. Dazu gehören gut strukturierte Retrospektiven ebenso wie offene und ehrliche Gespräche mit dem Team und mit einzelnen Mitgliedern. Die in Managementliteratur immer prominenter werdende Transparenz kann sich genauso durch Teamzusammenkünfte mit allen Personen wie auch im Einzelgespräch mit den Mitgliedern herauskristallisieren. Die vertrauensvollere Atmosphäre unter vier Augen lässt die ein oder andere Schwierigkeit in den Aufgaben oder im Team manchmal eher ans Licht kommen. Das verdeutlicht, dass ein guter Scrum Master Fingerspitzengefühl für unangenehme Situationen oder schwelende Konflikte benötigt, um diese zeitnah zu beseitigen, bevor daraus größere Probleme erwachsen.

Nachfolgend wollen wir den Dienstleistungscharakter der Scrum Master Rolle deutlicher herausarbeiten, indem wir uns anschauen, welche Aufgaben der Scrum Master in Bezug auf die anderen Scrum Rollen und die Organisation übernimmt.

Fangen wir mit der Organisation an. Wie eingangs kurz angedeutet, besteht die Hauptaufgabe darin, die Organisation mit Scrum vertraut zu machen. Das geschieht durch Trainings und Coachings. Der Scrum Master hat dabei natürlich auch eine beratende Funktion, in die er Erfahrungen aus anderen agilen Projekten mit einbringen sollte (sofern bereits vorhanden). Als größte Hürde hat sich dabei das Agile Mindset gezeigt. Es zeigt sich in der Praxis immer wieder, dass es für Unternehmen eine Hürde ist, von einer über Jahrzehnte gelernten Denkweise, die hauptsächlich auf traditionellen Projekt- und Produktdurchführungsmethoden (Zeit, Geld, Umfang) basiert, loszulassen. Der Schritt weg von einer – sind wir ehrlich – gefühlten Sicherheit der Projekt- und Budgetpläne sowie der Lasten- und Pflichtenhefte hin zu einem empirischen Ansatz, der bewusst Experimentieren zulässt und damit Fehlschläge akzeptiert, ist oftmals deutlich schwieriger als man vermutet und ein Hauptgrund dafür, dass Agilität in Organisationen scheitert. Zu guter Letzt ist der Scrum Master dafür zuständig, sich um sämtliche Hindernisse, welche Gestalt auch immer diese annehmen mögen, zwischen dem Scrum Team und anderen Beteiligten innerhalb der Organisation zu kümmern und sie bestmöglich zu beseitigen.

Kommen wir zur Bedeutung des Scrum Masters für den Product Owner. Der Scrum Master unterstützt ihn bei der Definition und dem Management des Produktzieles und des Produkt Backlogs. Er übernimmt keine inhaltlichen Aufgaben, sondern bietet vielmehr Unterstützung und Techniken an, wie die zwei zuvor genannten Aufgaben erfolgreich umgesetzt werden können. Zudem fördert und erweitert der Scrum Master das tiefergehende Verständnis des Product Owners, die Relevanz klarer und prägnanter User Stories zu begreifen und diese entsprechend umzusetzen (ein Punkt, der auch vom gesamten Team verstanden und mitgetragen werden muss – eine weitere Aufgabe des Scrum Masters). Zwar ist der Scrum Master selbst nicht der Product Owner (und hat unter Umständen keine eigene Produktentwicklungserfahrung, wenngleich das sehr hilfreich ist), dennoch gehört es zu seinen Aufgaben, dem Product Owner dabei zu helfen, geeignete Methoden hinsichtlich der Planung und Priorisierung der User Stories anzuwenden. In Lehrbüchern werden an dieser Stelle of Cost of Delay und Weighted Shortest Job First genannt. [Fußzeile: Cost of Delay bezeichnet dabei die Kosten, die auf ein Unternehmen zukämen, wenn eine bestimmte User Story erst zu einem späteren Zeitpunkt umgesetzt wird. Weighted Shortest Job First stellt den Nutzen einer User Story in Relation zum entsprechenden Aufwand und erlaubt damit, zumindest aus rein betriebswirtschaftlicher Sicht, eine optimale Priorisierung von User Stories.] Jedoch zeigt sich in der Praxis, dass Organisationen in Bezug auf Priorisierung von User Stories sehr kreativ sein können. Die Anwendung einer bestimmten Lehrbuchmethode ist dabei gar nicht entscheidend. Von höher Bedeutung ist, dass der Scrum Master die Dringlichkeit der Priorisierung herausstellt. Argumente à la „wir müssen das unbedingt im nächsten Sprint machen, weil wir es brauchen“ sollten nicht akzeptiert werden. Ebenso fungiert der Scrum Master als Vermittler und unterstützt, soweit erwünscht oder notwendig, den Product Owner bei der Zusammenarbeit mit anderen Beteiligten aus der Organisation.

Im Team äußert sich der Dienstleistungscharakter des Scrum Masters in der Form, als dass dieser alle Teammitglieder kontinuierlich darin coacht, ihre Zeit und Arbeit selbst zu managen. Er begleitet sie auf dem Weg in ein crossfunktionales Umfeld, was für einige zu Beginn noch ein ungewohntes Terrain darstellt. Einer der Gründe, weshalb Agilität nicht erfolgreich in eine Organisation implementiert wird, kann sein, dass dieser Punkt schlichtweg unterschätzt wurde. Teammitglieder benötigen Zeit und lernen erst, mit der neuen Freiheit in einem agilen Umfeld umzugehen. Wenn Personen mehrere Jahre in einem Umfeld gearbeitet haben, in dem sie von außen gemanagt wurden und Selbstorganisation unerwünscht war, ist die Wahrscheinlichkeit hoch, dass eine agile Umgebung erst einmal überfordernd ist. Der Scrum Master bezieht an diesem Punkt eine Leuchtturmposition. Durch Vorbild und Expertise verhindert er, dass eine Lähmung entsteht, in der Personen lieber nichts tun als Fehler zu begehen. Darüber hinaus unterstützt der Scrum Master das Team hinsichtlich der gemeinsam vereinbarten Definition of Done dabei, die Sprintziele zu erreichen. Er hilft dem Team dabei, sämtliche Hindernisse zu beseitigen, die zur Erreichung der Sprintzieles im Weg stehen. In der Praxis beinhaltet das die die Identifizierung von Abhängigkeiten und das entsprechende Management derselben. Folgende Situation wird anfangs immer mal wieder passieren und kann schnell in den Griff bekommen werden: Ein Sprint wird geplant, ohne die entsprechenden Abhängigkeiten der einzelnen User Stories zueinander zu berücksichtigen. Nicht selten führt das zu Situationen während eines Sprints, in denen einzelne Teammitglieder nicht weiterarbeiten können, da sie auf die Ergebnisse anderer Teammitglieder angewiesen sind (sogenannte Blocker). Der Scrum Master wird auch als Prozesswächter von Scrum bezeichnet. Damit ist gemeint, dass der Scrum Master dafür zu sorgen hat, dass alle Scrum Events stattfinden und innerhalb des vorgeschriebenen zeitlichen Rahmens bleiben.

Das gesamte Rahmenwerk Scrum kann und sollte individuell auf das Unternehmen, das Produkt und die Teammitglieder angepasst werden. Die Regeln nach Textbuch sind nicht dogmatisch zu verstehen. Es gab bereits erfolgreiche Scrum Teams, die bestimmte Events wie die Retrospektiven gestrichen haben. Genauso konnte so manches Scrum Team, das sich präzise an die Regeln gehalten hat, die gewünschten Ergebnisse nicht erreichen. Diese Freiheit ist ein wesentlicher Bestandteil von selbstorganisierenden Teams.

4.4 Product Owner als Wertmaximierer

Die Rolle des Product OwnersProduct Owner ist – im Vergleich zu den beiden anderen Rollen – innerhalb eines Scrum Teams diejenige, die durchaus unterschätzt wird. Außerdem stehen Fachbereiche vor personellen Herausforderungen, wenn sie einen ihrer Fachexperten für eine andere Tätigkeit abstellen müssen. Folgende zwei Kernaspekte entwickeln sich aus diesen Reibungspunkten:

1 Der Product Owner ist eine Rolle innerhalb der Organisation, die gegebenenfalls neu geschaffen werden muss! Optimal ist es, wenn sich der Product Owner vollständig auf die Tätigkeiten im Scrum Team fokussieren kann und keine zusätzlichen, anderweitigen Aufgaben erhält.

2 Der Product Owner ist eine (!) Person, keine Gruppe oder Komitee. Gleichzeitig kann er die Interessen mehrerer Personen vertreten. Die finale, produktbezogene Entscheidung obliegt jedoch immer dem Product Owner.

Welche Entscheidungen sind gemeint und was sind nun die konkreten Aufgaben eines Product Owners? Der Grundgedanke ist einfach: Der Product Owner trägt die Verantwortung dafür, den Wert zu maximieren, den das Produkt für das Unternehmen erzeugt. So generisch dies klingen mag, so vielfältig sind auch die Methoden, die ein Product Owner dabei anwenden kann.

Ein effektives Management des Product Backlogs bildet dabei das Herzstück, um den maximalen Wert aus dem Produkt zu kitzeln. Dazu gehören insbesondere das Herausarbeiten und Kommunizieren eines Produktziels. Hier kann es zu den ersten Differenzen kommen, die den Erfolg des Scrum Teams negativ beeinflussen. Das Team möchte schnelle sichtbare Ergebnisse erzielen. Das kann dazu führen, dass der strategische Part stiefmütterlich behandelt und aus den Augen verloren wird. Hier ist also besondere Aufmerksamkeit erforderlich: Stellen Sie im Laufe Ihres Projektes eine ungewünschte Veränderung der Ergebnisse fest, werfen Sie doch nochmal einen Blick auf die Ausarbeitungen und die Kommunikation des Produktziels. Nehmen Sie sich dafür Zeit, sie wird sich rentieren! User Stories zu erzeugen und zu kommunizieren ist ein weiterer Aufgabenbereich des Product Owners. Er bringt diese in eine sinnvolle Reihenfolge, was in der Praxis eine Herausforderung sein kann. Besonders in diesem Teilschritt treten veraltete, hierarchisch geprägte Denkweise ans Tageslicht, die dem agilen Grundgedanken widersprechen. Nehmen wir zur Illustration ein beispielhaftes Projekt, das sich mit dem Erstellen von Berichten beschäftigt. Es liegt nahe, zunächst einmal User Stories anzulegen, die sich lediglich mit dem Sammeln und Anbinden von Datenquellen beschäftigen, um dann, in einem zweiten Schritt, mit der Erstellung der Berichte zu beginnen. Das jedoch ist genau die traditionelle Wasserfall-Denkweise, die ein sequenzielles und kein inkrementelles Vorgehen vorsieht. Geht ein Product Owner so vor, würde er der Maxime Wertgenerierung entgegenarbeiten. Denn eines ist klar: Wert wird erst dann geschaffen, wenn mindestens ein Bericht von der Fachabteilung im operativen Betrieb genutzt werden kann. Deshalb wäre es ein – im Sinne eines Product Owners – geschickteres Vorgehen, zunächst einen wichtigen, wertgenerierenden Bericht auf Basis weniger Datenquellen zu erzeugen, um anschließend darauf aufbauend die Daten- und Berichtslandschaft zu erweitern Eine weitere, grundlegende Funktion des Product Owners ist, ein für alle Teammitglieder nachvollziehbares und transparentes Product Backlog sicherzustellen.