Wir erleben in unseren Kundeneinsätzen sehr oft, dass im Rahmen der “agilen Transformation” einzelner Einheiten neue Rollen vergeben werden, ohne dass ein ausreichendes Verständnis zu der Rolle und den erwarteten Ergebnissen und Tätigkeiten herrscht. Die Erarbeitung und Gestaltung digitaler Produkte (und damit ist nicht die rein visuelle Gestaltung gemeint), sind Aufgaben der Rollen, die wir allgemein als “Product People” bezeichnen. Dazu gehört neben dem Produktmanagement insbesondere der Product Owner.
Die konkreten Tätigkeiten der “Product People”, oder konkret des Product Owners, sind im Rahmen des Scrum Guides nur ansatzweise beschrieben. Dieser befasst sich vor allem mit der Ausgestaltung und angemessene Priorisierung des Product Backlogs. Die Zusammenarbeit mit nicht-agilen Teilen des Unternehmens ist nicht beleuchtet. Im Rahmen von selbstorganisierten und interdisziplinär zusammenarbeitenden Teams kann das ohne Struktur zu großen Schwierigkeiten und Effizienzverlust (Verschwendung) führen.
Grade im agilen Kontext ist ein systematischer und disziplinierter Ansatz notwendig, um den Fokus zu halten und sich im Rahmen der Randbedingungen frei und eigenverantwortlich bewegen zu können. Wir benötigen neben dem Product Backlog weitere Arbeitsprodukte.
Praxiserprobt ist der Weg von der Idee zur Umsetzung über folgende Artefakte, die aufeinander aufbauen und sich gegenseitig bedingen:
Die Produktvision als Nordstern und grundsätzliche Ausrichtung der weiteren Schritte
Das Big Picture inklusive Kontextabgrenzung für eine erste Scope-Definition und Identifikationen von Abhängigkeiten
Die Roadmap-Planung (Planung der Produktinkremente) für eine klare Zielsetzung der Produktentwicklung
Die Konzeption und Detaillierung der Inkremente über die Story Map
Das Formulieren von Backlog Items in Form von User Stories
Die Produktvision als Nordstern und Ausrichtung
Wir benötigen im agilen Kontext Orientierung. Besonders dann, wenn ein Unternehmen eine hohe Dynamik an Veränderungen erlebt und die klassischen Strukturen mehr und mehr wegfallen. Eine gut erarbeitete Produktvision bietet allen Mitarbeitern die Möglichkeit, ihr eigenes Tun immer wieder zu überprüfen und kontinuierlich auszurichten.
Auf dieser Abstaktionsebene geht es darum, zu definieren, was der Bedarf und das Ziel der Produktentwicklung ist. Es sollten u.a. folgende Fragen beantwortet werden können:
Haben wir ein gemeinsames Verständnis, worum es geht und welchen Wert das Produkt liefert?
Haben wir eine Basis, um Entscheidungen treffen zu können, um bestmöglich den Zweck des Produktes zu erfüllen?
Ist die geplante Investition im Sinne des Unternehmens?
Stecke ich meine Ressourcen in Funktion A oder B? Welches passt besser zur Vision useres Produktes?
Wie kooperiere ich mit Kunden, Partnern und Kollegen?
Canvas Modelle bieten die Möglichkeit, sich über passende Fragestellungen der Vision zu nähern. Wir empfehlen das Product Vision Board (von Roman Pichler), das Value Proposition Canvas oder das Business Modell Canvas. Hier geht es zu Vorlagen aus unserem Werkzeugkoffer → Bedarf ausrichten
Das Big-Picture für eine klare Scope-Definition
Die Vision alleine reicht nicht aus, um ein Product Backlog zu füllen und kontinuierlich weiter zu entwickeln. Wir benötigen eine Kontextabgrenzung und Scope-Definition (Umfang), um Entscheidungen bzgl. der Priorisierung und der weiteren (“just in time”) Detaillierung von Backlog Items treffen zu können. Das funktioniert nur, wenn auch das große Ganze, das “Big Picture”, bekannt ist und stets im Auge behalten wird. Im Gegensatz zur Vision wird das Big-Picture konkreter.
Das Use Case Diagramm mit einer Übersicht der Akteure, dem Systemkontext und den notwendigen Anwendungsfällen ist immer noch eine gute Hilfestellung auf der Ebene des “Big Pictures”, nicht nur im klassischen Lastenheft. So kann der grundsätzliche Funktionsumfang des digitalen Produktes abgesteckt werden und Schnittstellen zu anderen Systemen werden sichtbar. Abhängigkeiten können weiter aufgedeckt werden und, falls vorhanden, bei der Priorisierung der weiteren Aktivitäten berücksichtig werden.
Die folgenden Schritte werden dabei durchlaufen:
Wer sind die (primären und sekundären) Anwender meines digitalen Produktes
Welche Partnersysteme muss ich berücksichtigen und in das Stakeholdermanagement aufnehmen
Welchen (groben) Funktionsumfang wird benötigt
Welche Rolle und welches System interagiert zukünftig mit dem Produkt über welche Funktion (Anwendungsfall)
Hier geht es zu einem kurzen Erklärvideo zum Use Case Diagramm → Dokumentieren
Die agile Roadmap-Planung für eine klare Zielsetzung
Ohne klare und abgestimmte Ziele in die Produktentwicklung zu starten ist ein typisches agiles Missverständnis. Genau wie die Verwendung des Begriffs “MVP” als Rechtfertigungsversuch in die falsche Richtung gelaufen zu sein.
Auf Basis des Use Case Diagramms werden im klassischen, Phasen-orientierten Vorgehen alle Anwendungsfälle weiter ausgearbeitet inklusive aller relevanter Anforderungen. Im agilen Kontext geht es allerdings um die frühe und kontinuierliche Auslieferung von wertvoller Software. Der Scope und das Big-Picture muss deshalb in sinnvolle Teilziele heruntergebrochen werden.
Folgende Fragestellungen sollten bei der Roadmap Planung im agilen Kontext (in dieser Reihenfolge) geklärt werden:
Welche Iterationen sind für die Roadmap-Planung sinnvoll, d.h. in welchen Zeitintervallen soll Software produktiv ausgeliefert werden (max. alle 3 Monate, im Idealfall früher).
Was ist das Ziel pro Produktinkrement, welches mit der Auslieferung erreicht werden soll (Ziel für den Kunden und Ziel für das eigene Unternehmen).
Welche Funktionen (Features), abgeleitet aus den Anwendnungsfällen und dem Big Pictures, gehören zum jeweiligen Ziel.
Wie messen wir, in wie weit das Ziel am Ende der Iteration erreicht wurde.
Die Goal-oriented Roadmap von Roman Pichler bietet hier eine schöne Vorlage, um die Roadmap auf Basis der o.g. Fragestellungen abzuleiten. Die ersten 2 bis 3 Produktinkremente sind oft klarer, insbesondere mit Blick auf die Features der Iterationen. Releases weiter in der Zukunft dürfen noch Raum für Änderungen und neue Erkenntnisse haben.
Konzeption und Detaillierung der Inkremente über die Story Map
Wir nähern uns dem Product Backlog und konkreten Backlog Items. Auf Basis der Produktvision, dem Big Picture und der daraus abgeleiteten Roadmap Planung (Blick auf die kommenden 2 – 3 Produktinkremente) können wir uns jetzt der konkreten Ausgestaltung des Produktes weiter nähern und im interdisziplinären Team an der Detaillierung des Produkt Backlogs arbeiten.
Die Story Map ist ein nützliches Hilfsmittel, um genau das zu tun. Folgendes Schritte sind dabei wichtig:
Identifikation des wertvollsten Anwendungsfalls aus dem Use Case Diagramm oder Features der Roadmap Planung
Identifikation des Akteurs / Benutzers, der mit dem Produkt im Rahmen des gewählten Anwendungsfalls
Definition der Benutzerinteraktion, Schritt für Schritt. (Horizontale Elemente)
Definition möglicher Ausbaustufen der Produktfunktionen pro Interaktionsschritt (Vertikale Elemente)
Priorisierung der Ausbaustufen und festlegen des konkreten Umfangs pro Release mit Blick auf den Zielen Roadmap Planung.
Das Ergebnis der Story Map ist eine zweidimensionale Darstellung aller Anforderungen / Funktionen, die in das Backlog überführt werden können. Dabei muss nicht 1:1 eine Karte der Story Map zu einem Backlog Item gehören. Das spätere Ausdetaillieren und Teilen der Karten in kleinere Backlog Items ist durchaus sinnvoll.
Formulieren von Backlog Items in Form von User Stories
Auf Basis der Story Map kann das Backlog ausgestaltet werden, und das direkt in der richtigen Priorisierung! Die Formulierung von Bedarfen der Nutzer ist die Basis für den Austausch mit dem Team und der weiteren Einschränkung des Lösungsraums im Rahmen der Produktentwicklung. Das ist auch einer der Gründe, warum sich im agilen Kontext die Verwendung von “User Stories” gegen die Formulierung von (System-) Anforderungen durchgesetzt hat.
Hier finden Sie mehr Tipps zu User Stories
Fazit
Im agilen Kontext ist oft nicht klar, welche Arbeitsprodukte im Rahmen der Anforderungsvermittlung benötigt werden und was neben den definierten Artefakten über den Scrum Guide notwendig ist. Die o.g. fünf Schritten von der Vision zur User Story sind essenziell für eine fokussierte Zusammenarbeit, haben sich in der Praxis erprobt und können über klare Methoden und Vorlagen angewendet werden.
Sie möchten mehr zu diesem Thema erfahren?
WordPress Cookie-Hinweis von Real Cookie Banner