Kitabı oku: «Der Scrum-Reiseführer», sayfa 4

5.1.1 Von der Produktidee zur Produktvision

Am Anfang steht die ProduktideeProduktidee, die mithilfe der ProduktvisionProduktvision beschrieben wird. Diese Produktvision soll die Projektstakeholder positiv auf die anstehenden Veränderungen, die sich mit der Einführung des Produkts ergeben, einstimmen. Sie schafft die tägliche Motivation, an einem Produkt zu arbeiten, das einen echten Zweck erfüllt. Eine Produktvision muss kurz und prägnant formuliert werden. Sie darf nicht langweilen und soll dabei die Neugierde auf das Produkt steigern. Das Projektteam sollte das Gefühl haben, an etwas Großem beteiligt zu sein. So darf die Produktvision beispielsweise nicht formuliert werden: „Mit einem Budget von 257.129 Euro wollen wir das Produkt Personalverwaltung I durch das Produkt Personalverwaltung II ersetzen. Beide Produkte haben exakt den gleichen Funktionsumfang, Personalverwaltung II ist nur schneller als Personalverwaltung I. Personalverwaltung II wird am 31.12.2055 produktiv gehen.“ Bei einer solchen Produktvision können sich die Projektmitarbeit schwer mit dem Produkt identifizieren. Sollten sie Zweifel gehabt haben, ob sie im richtigen Projekt sind, trägt dieser Vision eher dazu bei, dass sich die Mitarbeiter dazu motiviert fühlen, ein anderes Projekt zu suchen. Das Negativbeispiel ist nicht nur demotivierend formuliert, es ist auch eine Mischung aus Zielen, Erfolgsfaktoren und einer Roadmap. Genau darin liegt auch das Problem bei vielen Produktvisionen. Es werden verschiedene Themenstellungen gleichzeitig adressiert.

Eine Produktvision soll inspirieren und dabei langfristig auf circa drei bis fünf Jahre ausgelegt sein. Ziel ist, ein klares, positives Bild des Produktes in den Köpfen der Empfänger zu zeichnen, wobei die jeweiligen Vorstellungen nicht übereinstimmen müssen. Die Teammitglieder erhalten ein realistisches Ziel, das aber nicht zwingend erreicht werden muss. Die Produktvision beschreibt keine konkrete Vorgehensweise und auch keinen spezifischen Funktionsumfang. Der Erfüllungsgrad der Vision ist nicht durch Kennzahlen messbar. Es ist außerdem denkbar, dass sich die Vision im Laufe der Zeit verändert, auch wenn dies eine Ausnahme bleiben sollte. So ungewöhnlich oder ambitioniert einige Visionen wirken, so einprägsam sind sie in der Regel auch. In der IT-Branche wird gerne die Vision, die Googles Suchmaschine zugrunde liegt, als Paradebeispiel angeführt: „to provide access to the worlds information in one click“. Diese Vision wird von folgender übergeordneten Mission abgeleitet: „to organize the worlds information and make it universally accessible and useful“. Ein weiteres Positivbeispiel ist Audis Unternehmensvision „Mobilität mit null Emissionen“. Stellen Sie sich vor, das Unternehmen hätte stattdessen die Vision „Sicherstellung der Mobilität trotz vollständiger Vermeidung von Emissionen durch die Umstellung der Fahrzeugflotte auf Elektroantrieb“ gewählt. Eine solche Vision wäre nicht einprägsam und es ist schwierig, sich damit zu identifizieren. In beiden Fällen handelt es sich um Unternehmensvisionen; Produktvision sollten genauso formuliert werden.

Bei der Formulierung der Produktvision können Sie die SHIELD-Kriterien als Hilfestellung verwenden. Dieses Akronym enthält die Anfangsbuchstaben der englischen Begriffe simple, huge, important, engaging, long-term und distributed. Die Produktvision sollte also einfach zu verstehen sein (simple), ein großes Ziel beschreiben (huge), ein bedeutendes Bedürfnis adressieren (important), alle Beteiligten einnehmen (engaging), langfristig ausgerichtet sein (long-term) und allen im Unternehmen bekannt sein (distributed).

Nun stellt sich die Frage, wer für die Formulierung der Produktvision verantwortlich ist. Es ist keine gute Idee, diese Aufgabe dem Product Owner zu übertragen. Stattdessen sollte eine Stakeholder-Analyse gemacht werden, um geeignete Personen mit den benötigten Kompetenzen zu identifizieren.

5.1.2 Von der Produktvision zur Produktstrategie

Nachdem die Produktvision festgelegt wurde, geht es an die ProduktstrategieProduktstrategie (siehe Abbildung 11).

Die Entwicklung der Produktstrategie ist keine strategische Planung im klassischen Sinne. Die relevanten Produktmerkmale kristallisieren sich oft erst während der iterativen Produktentwicklung heraus. Man sollte den Strategieprozess daher damit starten, dass ausgewählte Stakeholder die Zielgruppe des Produkts festlegen. Denn nur die zukünftigen Kunden und Verwender des Produkts können letztlich beschreiben, welchen Nutzen das Produkt für sie hat. Es kann sein, dass hierbei eine Unterscheidung zwischen Kunden und Anwendern erforderlich ist, denn ein Kunde ist nicht notwendigerweise auch der Anwender eines Produkts. Die beiden Gruppen können unterschiedliche Zielvorstellungen haben, die bei der Formulierung der Produktstrategie zu berücksichtigen sind.

Abbildung 11:

Produktstrategie

Wer identifiziert also die Zielgruppe? Welche Stakeholder gehören dazu? In jedem Fall ist der Product Owner einer davon. Neben diesem Hauptakteur gehören auch Vertreter aus dem Marketing, dem Verkauf und dem Service in diese Gruppe. Bei strategisch bedeutsamen Produkten sollte sich auch die Unternehmensleitung an diesem Auswahlprozess beteiligen.

Ist die Zielgruppe identifiziert, wird im nächsten Schritt der Produktnutzen aus deren Sicht herausgearbeitet. Dieser wird so lange beschreiben, bis der Mehrwert deutlich heraussticht. Dieser kann sein, dass eine bisher vorhandene Anwenderherausforderung behoben wird oder das Produkt einen zusätzlichen Nutzen für den Kunden schafft. Wenn zum Beispiel die Abarbeitung eines Backoffice-Prozesses zu lange dauert, weil das verwendete IT-System zu langsam ist, würde die Nutzenbeschreibung folgendermaßen lauten: „Performantes IT-System, um Bearbeitungs- und Wartezeiten zu verkürzen“. Das formulierte Ziel sollte erreichbar und flexibel sein. In unserem Beispiel ist das der Fall. Bereits mit der Einführung eines neuen IT-Systems, bei dem die Prozessdauer um eine Sekunde verkürzt würde, wäre das formulierte Ziel erreicht, da jede noch so minimale Verkürzung der Prozessdauer das Ziel erfüllen würde. Die Nutzenbeschreibung ist genauso flexibel, da nicht festgelegt ist, um wie viele Sekunden oder Minuten die Bearbeitungs- und die Wartezeit verkürzt werden soll.

Gänzlich auf Zielvorgaben zu verzichten, ist nicht sinnvoll, schließlich erhofft sich die Zielgruppe durch die Anwendung des Produkts einen signifikanten Mehrwert. Um nachhalten zu können, ob dieses Ergebnis erreicht wurde, sollten die Ziele messbar gestaltet werden. Für jedes Ziel finden dann eine oder mehrere Kennzahlen Anwendung. Die Zielvorgaben sollte man nicht mit absoluten Größen, sondern in Form von Anteilsgrößen definieren. Eine Zielformulierung in Form von absoluten Werten erfolgt, wenn die Product Roadmap mit Inhalt gefüllt wird. Wenn möglich, sollte immer ein Zielkorridor und kein Einzelwert benannt werden. In unserem Beispiel würde man vielleicht im ersten Schritt eine Reduzierung der Bearbeitungs- und Wartezeiten um 5 bis 10 % und im zweiten Schritt um 10 bis 20 % anstreben.

Sobald die Ziele aus der Perspektive der Zielgruppen definiert sind, bleibt die Frage, welche Vorteile sich für das Unternehmen ergeben (siehe Abbildung 12). Daher sind im nächsten Schritt die Business-Ziele festzulegen. Typische Erwartungen an das neue Produkt sind beispielsweise ein höherer Umsatz, mehr Gewinn, Kostenreduktion und die Erschließung neuer Geschäftsfelder. Diese Ziele sind wertvoll und – wie alle Ziele – sollten sie messbar sein, um später prüfen zu können, ob sie erreicht wurden. Ein Zielformulierung könnte lauten: „Umsatzsteigerung durch Klicks auf Werbelinks“. Dies wird messbar durch die Anzahl der Klicks. Wie jedoch mehr Klicks erreicht werden können, dazu gibt das Ziel keine Auskunft. Das ist im ersten Schritt auch gut so. Die Methoden können später festgelegt werden, was Raum für kreative Lösungen gibt.

Abbildung 12:

Inhalte Produktstrategie

Im folgenden Schritt erreichen wir die ersten Ebenen der Backlog Elemente (Initiativen, Features oder Epics). Es geht um die grobe Unterteilung in Hauptfunktionen. Ziel ist es, das Produkt mithilfe wesentlicher Hauptfunktionen zu beschreiben. Diese Features können sich auf funktionale und nichtfunktionale Anforderungen beziehen. In der Regel genügen drei bis zehn Elemente. Bei den Hauptanforderungen sollte auch vermerkt werden, ob es sich um einen Industriestandard oder eine innovative Neuerung handelt. Wünschenswert für einen Produkterfolg sind vor allem die Hauptanforderungen, die ein Alleinstellungsmerkmal am Markt haben oder eine deutliche Verbesserung gegenüber dem Standard versprechen. Für die Klassifizierung können beispielsweise folgende Unterteilungen verwendet werden:

 Innovation (Alleinstellungsmerkmal): Diese Anforderungen sollten unbedingt und frühzeitig umgesetzt werden.

 Verbesserung gegenüber Industriestandard: Diese Anforderungen sollten umgesetzt werden

 Standard- bzw. Basisfunktion: Diese Anforderungen entsprechen dem Industriestandard oder liegen darunter. Daher sollte geprüft werden, ob und in welchem Umfang sie wirklich benötigt werden.

5.1.3 Von der Produktstrategie zu den Produktzielen

Nachdem nun die Ziele für die verschiedenen Ebenen ermittelt wurden, ist es an der Zeit, über die Erfolgsfaktoren nachzudenken. Beim klassischen Projektmanagement hat man immer die Zieldimensionen Zeit, Kosten und Leistung im Blick. Deren Abhängigkeiten voneinander aufmerksam zu berücksichtigen ist von Bedeutung, da diese drei Größen in direkter Verbindung zueinanderstehen (siehe Abbildung 13).

Abbildung 13:

Magisches Dreieck

Als Erweiterung zum magischen DreieckMagisches Dreieck gibt es auch noch das TeufelsquadratTeufelsquadrat (siehe Abbildung 14). Bei diesem Quadrat wird die Leistungsdimension in die zwei Dimensionen Inhalt und Qualität aufgespalten. Werden alle Dimensionen des magischen Dreiecks oder des Teufelsquadrats (weitestgehend) erfüllt, spricht man von einem erfolgreichen Projekt.

Abbildung 14:

Teufelsquadrat

Sind diese Kriterien ein guter Maßstab, den Erfolg eines Projekts zu messen? Wer sagt denn, dass ein Projekt nicht bereits erfolgreich sein kann, wenn nur 60 % des Inhalts umgesetzt wurde und das innerhalb der Hälfte der Zeit. Das Projektbudget wurde zwar um 10 % überzogen, mit dem neuen Produkt erhöht sich jedoch der Umsatz gegenüber dem Vormonat um 20 % und das obwohl noch 40 % der Anforderungen fehlen. Natürlich sind Kosten, Leistung, Inhalt und Zeit weiterhin wichtige Erfolgsfaktoren. Gleichzeitig werden weitere Kriterien berücksichtigt. Was bedeutet es in unserem fiktiven Beispiel für den Projekterfolg, wenn sich aufgrund einer geringeren Produktqualität der Serviceaufwand um ein Fünftel erhöht? Welche Konsequenzen hat es, dass eine hohe Fehleranzahl dazu führt, dass die Kunden das Produkt nicht kaufen möchten? Was wäre, wenn man die Produktqualität im nächsten Release nur um 3 % verbessern würde, aber ein neues Feature, das ein Alleinstellungsmerkmal ist, implementieren würde und sich dadurch der Umsatz um 25 % steigern würde?

Kosten, Zeit, Inhalt und Qualität bleiben weiterhin wesentliche Erfolgsfaktoren. Dennoch bedürfen sie einer Erweiterung um den Funktionsumfang, den Marktanteil (insbesondere, wenn es relevante Mitbewerber gibt) und den generierten Wert. Der Wert der Produktanforderungen, auch als Business Value bezeichnet, wird uns später intensiver beschäftigen. Abhängig davon, welche Erfolgsfaktoren man für ein Produkt zugrunde legt, ist die Projektvorgehensweise darauf abzustimmen. Soll zum Beispiel ein fester Liefertermin eingehalten werden, richten sich sämtliche Bestrebungen danach. Kosten, Inhalt, Qualität und Funktionsumfang würden kaum beachtet werden. Stattdessen würden wahrscheinlich viele kostenintensive Experten mit den notwendigen Erfahrungen einkauft werden, das Produkt in kürzester Zeit mit minimalem Funktionsumfang so einfach wie möglich umsetzen.

Abbildung 15:

Produktziele

Für der Produktentwicklung sollte also nicht ein einziges Produktziel verwendet werden, sondern mehrere. Im Scrum Guide steht, dass das ProduktzielProduktziel das langfristige Ziel für das Scrum Team sei und, dass erst eine Zielvorgabe erfüllt sein sollte, bevor es an die nächste geht. Jedoch steht im Guide nicht, dass es für das Projektprodukt nicht ein Ziel gibt. Es wird auch nicht genauer festgelegt, was ein langfristiges Ziel ist. Dieses kann individuell festgelegt werden. Wenn die Sprintdauer beispielsweise eine Woche beträgt, können drei Monate durchaus lang sein. Es spricht daher nichts dagegen, mehrere Produktziele zu definieren.

Wie viele Produktziele werden gebraucht? Mindestens so viele, wie benötigt werden, um die strategischen Ziele erreichen zu können. Das mag sich pauschal anhören, dahinter verbirgt sich jedoch ein hohes Maß an Agilität. Es bedeutet, dass keine feste Anzahl an Produktzielen für die strategischen Ziele erreicht werden muss. Es kann also sein, dass sich die Produktziele ändern, neue hinzukommen oder welche entfallen und daher Anpassungen an den strategischen Zielen notwendig werden. Dies erfordert möglicherweise auch Anpassungen an der Vision. Der Weg von der Vision bis zum Sprintziel wird nicht nur einmal durchlaufen, sondern immer wieder – ganz nach dem agilen Verständnis.

Wie sollte nun ein einzelnes Produktziel gestaltet werden? Kurz und deutlich. Ein Ziel könnte zum Beispiel die „Verbesserung der Benutzererfahrung bei Verkaufsauswertungen“ sein. Da Ziele immer messbar sein müssen, könnten Sie hierfür beispielsweise die Metriken Kundenzufriedenheit oder Nutzungsdauer verwenden. Legen Sie zusätzliche relevante Erfolgsfaktoren fest. Achten Sie in den Zeitdimensionen darauf, dass Sie nicht zu weit in die Zukunft gehen. Dabei sollte der Zeithorizont zwischen sechs und maximal zwölf Monate liegen.

Die Produktziele sind auch die Basis für eine gute Strukturierung des Backlogs. So erreichen Sie, dass das Backlog immer am nächsten Ziel ausgerichtet wird. Das bedeutet, das Backlog enthält keine überflüssigen oder redundanten Product Backlog-Elemente. Das macht es für das Team einfacher, sich auf das nächste Ziel zu fokussieren, anstatt mit Themen konfrontiert zu werden, die erst viel später in der Produktentwicklung benötigt werden. Hinzu kommt, dass Sprintziele einfacher abgeleitet werden können. Diese sind auch immer am nächsten und nicht schon am übernächsten Produktziel ausrichtet.

5.1.4 Von den Produktzielen zu den Sprintzielen und zurück zur Vision

Auf Basis der Produktziele kann eine Product RoadmapProduct Roadmap erstellt werden. Der Begriff Roadmap lässt einen Wasserfall-Ansatz vermuten. Sie ist jedoch eine Strukturierungshilfe für die Produktziele. Für einen überschaubaren Zeithorizont wird der Weg zum nächsten Produktziel aufgezeigt.

Abbildung 16:

Einordnung der Product Roadmap

Hierbei können unterschiedliche Roadmap-Typen zum Einsatz kommen. Die wohl bekannteste Roadmap ist an den Funktionen des Gesamtproduktes bzw. des nächsten Produktziels (auf Ebene der Features oder Epics) ausgerichtet. Abbildung 17 zeigt eine solche Feature RoadmapFeature Roadmap.

Abbildung 17:

Feature Roadmap

Die Feature Roadmap wird meistens für einen größeren Zeithorizont genutzt. Typisch sind Zeiträume von größer als einem Jahr. Wenn es viele Features gibt, kann die Roadmap schnell unübersichtlich werden und die Abhängigkeiten zwischen den Features werden nicht ausreichend berücksichtigt. In solchen Konstellationen hat sich die zielorientierte RoadmapZielorientierte Roadmap bewährt (siehe Abbildung 18). Bei dieser Roadmap erfolgt die Strukturierung anhand von Hauptfunktionen zu einem Ziel auf der Roadmap. Dadurch bleibt die übergeordnete Sichtweise auf die Basis der Ziele erhalten, die Details sind ebenfalls erkennbar. Das Backlog ist damit klarer strukturiert. Bei der zielorientierten Roadmap wird, je nach Produktausprägung, ein Zeitraum von sechs Monaten bis zu maximal einem Jahr genutzt, wobei alle ein bis drei Monate eine Überprüfung und Anpassung anhand der Sprintergebnisse vorgenommen werden sollte.

Abbildung 18:

Zielorientierte Roadmap

Ein weiterer Vorteil der zielorientierten Roadmap ist, dass sie Roadmap-Ziele hat. Entweder werden kurzfristige Produktziele abgebildet – dann sind bereits alle Anforderungen an die Ziele erfüllt – oder sie werden durch Unterziele auf dem Weg zu den nächsten Produktzielen ergänzt. Im zweiten Fall sind für die Unterziele ebenfalls die grundlegenden Kriterien für Ziele zu erfüllen. Zumindest sollte jedem Unterziel eine sinnvolle Metrik, mit der die Zielerreichung gemessen wird, zugewiesen werden. So können der Entwicklungsfortschritt und die damit einhergehende Wertsteigerung auf dem Weg zum Produktziel geprüft werden.

Die Features der zielorientierten Roadmap lassen sich einfach auf die Formulierung der Sprintziele übertragen. Im Grunde stellt dieser Übertrag die gleiche Beziehung wie zwischen Produktzielen und deren Unterzielen in der Roadmap dar. Ein Sprintziel wird erst bei der Sprintplanung vom Scrum Team formuliert und ist die selbstverpflichtende Zielvorgabe für den aktuellen Sprint, ohne dabei zu definieren, welche Arbeit dafür erforderlich ist. Dadurch bleibt die Flexibilität erhalten.

In der Praxis ist dieser einfach klingende Ansatz schwieriger umzusetzen. Ein Grund dafür kann sein, dass nicht fokussiert genug auf ein Produktziel hingearbeitet wird. Möglicherweise gibt es auch zu viele Vorstellungen darüber, was im nächsten Sprint umgesetzt werden sollte, um das Produktziel zu erreichen. Einige Teammitglieder denken vielleicht an neue Funktionen, während andere der Meinung sind, dass erstmal die Infrastruktur erweitert und bereitgestellt werden müssen. Beides kann richtig sein und zum Sprintziel passen, muss es aber eben nicht. So wird die Festlegung auf ein Sprintziel zu einer Herausforderung. Achten Sie darauf, dass Sie sich am Ende auf ein Sprintziel verständigen und diese Diskussion nicht mit einer Reihe oder sogar ohne ein echtes Sprintziel endet.

Schließen Sie eine Funktion alle zwei bis drei Sprints immer auf der Feature- oder Epic-Ebene ab (siehe Abbildung 19). Die Sprintziele lassen sich so wesentlich konkreter formulieren. In diesem Szenario könnte das erste Sprintziel daher „Bereitstellung der Infrastruktur“ lauten. Das zweite Ziel könnten Sie als „Verbesserung von Feature XY“ festlegen. Auf diese Weise wird das Team motiviert, gemeinsam auf ein Thema hinzuarbeiten, anstatt alles parallel machen zu wollen und an unterschiedlichen Themen zu arbeiten. Selbstverständlich darf die agile Vorgehensweise bei der Entwicklung der Sprintziele nicht zu kurz kommen. Sollte sich während eines Sprints herausstellen, dass aufgrund eines unerwarteten Aufwands oder einer blockierten Aufgabe nicht alles erledigt werden kann, ermitteln Sie gemeinsam mit dem Product Owner, ob das das Sprint Backlog reduziert wird. Das Sprintziel sollte dabei nicht verändert werden. „Alle User Stories aus der Sprintplanung sind zu erledigen“ ist daher kein sinnvolles Sprintziel. Es muss auch dann erreicht werden können, wenn es nicht vollständig der Planung entspricht. Das Sprintziel „Reduzierung der Code-Komplexität von Feature XY“ bietet zum Beispiel ausreichend Spielraum.

Abbildung 19:

Produkttaktik

Im obigen Sprintziel aus den Bereich Refactoring könnte es das Ziel sein, eine 20-prozentige Verbesserung der Code-Komplexität zu erreichen. Was passiert, wenn nur 19 % erreicht wurden? Lässt sich dann noch immer von Erfolg sprechen? Vermeiden Sie deshalb vage Begriffe wie Erfolg oder Erfüllung von Zielen. Deutlicher wird es am Beispiel der Sorites-Paradoxie (Paradoxie des Haufens) oder an der Paradoxie des Eubulides (Paradoxie vom Kahlköpfigen). Die Sorites-Paradoxie beinhaltet die Frage, ab wann ein Sandhaufen kein Sandhaufen mehr ist, wenn einzelne Sandkörner entfernt werden.

 Gegeben: Ein Sandhaufen, aus dem einzelne Körner entfernt werden.

 Annahme: Das Entfernen eines einzelnen Korns verwandelt einen Haufen nicht in einen Nicht-Haufen.

 Paradoxie: Was passiert, wenn bei der bestehenden Annahme der Prozess „Entfernen eines einzelnen Sandkorns“ oft genug wiederholt wird? Ist ein einzelnes Sandkorn dann noch ein Haufen? Wenn nicht, wann hat es sich von einem Haufen in einen Nicht-Haufen verändert? Ist ein Sandhaufen durch die Anzahl der Körner definiert? Wenn ja, was ist, wenn alle Körner nebeneinander angeordnet sind?

Die Paradoxie des Eubulides stellt die Frage, wie viele Haare ein Mensch besitzen muss, um nicht als kahlköpfig zu gelten. Beiden Paradoxien liegt die Annahme zugrunde, dass ein einzelnes Sandkorn oder ein einzelnes Haar nicht über die Ausprägung Haufen oder behaart oder kein Haufen bzw. kahl entscheiden könne. Die Paradoxie zeigt sich in beiden Fällen, wenn versucht wird, etwas zu bestimmen, für das keine genaue Definition existiert.

Dieser Herausforderung können Sie umgehen, indem ein fester Grenzwert festgelegt wird. (Beispiel: 20-prozentige Reduzierung der Komplexität des Programmcodes). Gängige Praxis ist auch, einen Grenzbereich (Beispiel: 15- bis 20-prozentige Reduzierung der Komplexität des Programmcodes) oder mehrere Grenzwerte (Beispiel: Bei unter 8 bis 10 % ist das Ziel nicht erreicht, zwischen 10 und 15 % ist das Ziel erfüllt, bei über 15 % wird das Ziel übertroffen) zu verwenden. Sie können auch im Gruppenkonsens prüfen, ob das Ziel erreicht wurde (Beispiel: Gruppe entscheidet, ob die Verbesserung der Programmcodes ein Erfolg war). Lassen Sie bei der Bewertung genügend Spielraum. Welches Team hat schon Lust, das Sprintziel regelmäßig zu verfehlen, obwohl es nur wenige Prozentpunkte hinter den Zielvorgaben liegt?

Abbildung 20:

Überprüfungsintervalle von der Taktik bis zur Vision

Wie auch immer die Sprintziele bewertet werden, sie haben Auswirkungen auf das nächste Ziel der Product Roadmap. Daher sollten die Sprintergebnisse, abhängig von der Länge der Sprints, alle paar Wochen oder nach zwei bis drei Sprints dahingehend untersucht werden, ob das nächste Ziel auf der Product Roadmap noch realistisch ist. Abhängig davon kann das nächste Sprintziel darauf ausgerichtet werden. Vielleicht ist auch eine Korrektur der Ziele auf der Roadmap notwendig, um das nächste Produktziel zu erreichen. Daher sollte auch die Roadmap alle paar Monate (abhängig vom Roadmap-Typ, der Sprintlänge und den Produkttypen) überprüft und angepasst werden. Wenn anhand der Roadmap erkannt wird, dass ein Produktziel nicht erreicht wird oder obsolet geworden ist, sollte auch das Produktziel angepasst werden. Das sollte alle zwei bis neun Monate erledigt werden. Das Gleiche gilt für die Produktstrategie und die Vision. Prüfen Sie diese alle sechs bis zwölf Monate und nehmen Sie entsprechende Anpassungen vor. So erreicht man eine Rückkopplung von den Sprintergebnissen bis hin zur Produktvision (siehe Abbildung 20).

Abbildung 21:

Schritte von der Produktidee zu den Sprintzielen

In Abbildung 21 sind nochmal die wesentlichen Schritte auf dem Weg von der Produktidee zu den Sprintzielen zusammengefasst. Abbildung 22 zeigt die Rückkopplung, ausgehend von Sprintergebnissen bis hin zur Anpassung der Produktausrichtung.

Abbildung 22:

Von den Sprintergebnissen zur Anpassung der Produktausrichtung