Der Scrum-Reiseführer. Tobias Renk

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