Produkt Roadmap

Wie schon geschrieben, enthält die Produkt Roadmap einen Aktions- oder Fahrplan mit Terminen, Funktionen und Zielen und beschreibt damit die Umsetzung der Produkt Strategie.

Auf einer Art Zeitachse werden innerhalb der Roadmap alle Vorgänge und deren Abhängigkeiten untereinander, aber auch zu externen Gegebenheiten abgebildet.

Sind die Anforderungen bereits aufgeteilt in Epics und User Stories, so kann man ganz einfach diese in der Roadmap vermerken. Anderenfalls werden die Themen ganz normal aufgezählt. Man sollte nur darauf achten, dass man sie so beschreibt, dass klar ist, was damit gemeint ist. Eine Formulierung wie “die Anpassung der Registrierung” sagt nichts über die Anforderung aus. Besser wäre in dem Fall zu schreiben, was denn angepasst werden soll.

Hier mal ein Beispiel einer mittels Jira erstellten Roadmap. Für diese Darstellung habe ich unser Beispielprojekt des Lernportals zur Hilfe genommen und die Ansicht auf monatlich eingestellt. Es bildet natürlich nur einen sehr kleinen Teil eines wirklichen Projektes ab und dient lediglich zur Veranschaulichung.

Der Vorteil bei der Jira Roadmap besteht darin, dass die User Stories schon automatisch hinzugefügt werden, wenn man den Epic der Roadmap zuweist. Die Status der Einträge werden ebenfalls automatisiert immer aktuell angezeigt. Abhängigkeiten kann man mit den geschwungenen Pfeilen darstellen. Ein weiterer Vorteil für die Abbildung des Workflows mittels Jira ist, dass man durch die Verlinkung direkt aus der Roadmap in die einzelnen User Stories springen kann.

Hier haben wir eine andere Beispieldarstellung einer Roadmap mittels eines Tabellenkalkulationstools. Dieses ist zwar hinsichtlich der Statusanzeige der Vorgänge statisch, aber dafür ist man in der Gestaltung freier als bei vorgefertigten Roadmapintegrationen.

In unserem Beispiel nun sehen wir die Vorgänge auf der linken Seite. Oben haben wir eine Info zu Monat und Datum, und in welchem Sprint wir uns in den jeweiligen Zeiten befinden. Die gewählte Sprintlänge beträgt in in dem Fall zwei Wochen.

Damit bildet die Product Roadmap das Product Backlog ab, bringt allerdings die zeitliche Komponente zum Ausdruck und strukturiert es. Inhaltlich ist die Roadmap natürlich weniger ausführlich als die Stories im Backlog geschrieben sind. Aber die inhaltliche Tiefe der Anforderungen ist auch nicht die Aufgabe einer Produkt Roadmap. Sie soll einen Überblick über alle Themen im Projekt bzw. zum Produkt verschaffen und Aussagen wie “wann fängt diese Umsetzung an” oder “wie lange wird jene Umsetzung dauern” ermöglichen. Das Einschätzen der Zeiten wird durch verfeinerte, geschätzte Userstorys und der Berechnung der Velocity möglich.

Des Weiteren sieht man auf den ersten Blick, welche Features von welchen anderen Items abhängig sind und verhindert so, dass man bei einer eventuellen Umplanung von bestimmten Vorgängen Fehler bei der Priorisierung begeht. Da Release-Zeitpunkte und Meilensteine ebenfalls in der Roadmap ersichtlich sind, vereinfacht dies das Priorisieren der verschiedenen Anforderungen ungemein.

Es gibt aber auch Abhängigkeiten die sozusagen von außen einwirken und ebenfalls in der Roadmap ihren Platz finden. Das können Marketingaktionen sein – Veröffentlichungen, Bekanntgaben, Messen und Veranstaltungen oder auch eine Werbeaktion. Vor größeren Releases kann man auch einen Kompletttest für die Testabteilung ansetzen und diesen dann in der Roadmap vermerken. Hat man für sein Produkt verschiedene Kunden, so wird innerhalb der Roadmap auch das Datum des Going Lives des Produktes bei dem jeweiligen Kunden angegeben.

Man kann also sagen, dass alle wichtigen Informationen in einem Dokument gebündelt werden. Nichts darf vergessen werden. Alle Stakeholder und Teams sollten immer die aktuellste Fassung der Roadmap zur Verfügung haben. Damit sind alle Teilnehmer des Projektes auf dem gleichen Stand. Das ist wichtig, denn die Roadmap dient als Grundlage für Besprechungen und Diskussionen – vor allem für den Product Owner im Gespräch mit den Skateholdern. Das gemeinsame Priorisieren und das Hin- und Herschieben der Features wird dabei wesentlich einfacher.

Mit einer gut gepflegten Roadmap ist der Product Owner also aussagekräftig.

Was muss aber beim Roadmap pflegen beachtet werden?

Wenn es mehrere Skateholder zum Projekt gibt, sollte man bei Änderungen am besten alle zusammen bringen, damit sofort jeder von ihnen Abhängigkeiten mitbekommt und gegebenenfalls Einwände bringen kann. Die Änderungen sollten dann unbedingt mit allen anderen Abteilungen abgesprochen werden, da auch da Abhängigkeiten bestehen könnten. Die neue bzw. aktualisierte Roadmap muss allen zur Verfügung gestellt werden bzw. darüber informiert werden, dass sich etwas geändert hat und was genau anders ist. Ansonsten riskiert man Verwirrungen im weiteren Projektworkflow.

Des Weiteren sollte auch darauf geachtet werden, dass sich die Roadmap nicht zu oft in zu kurzen Zeitabschnitten ändert – dies bringt Unruhe in das Projekt. Die Arbeit der Entwickler leidet irgendwann darunter und der Fokus geht eventuell verloren.

Wichtig ist, dass alle Teilnehmer mit der Art und Weise, wie die Roadmap aufgebaut ist, konform gehen und sie akzeptieren. Immerhin benötigen wir als Product Owner die komplette Mitarbeit der Stakeholder und des Teams. Dafür benötigen wir die volle Aufmerksamkeit und das komplette Interesse der Teilnehmer an der Produktentwicklung. Wenn sie sich nun herum schlagen müssen mit einer für sie nicht gut gestalteten oder vewirrenden Roadmap, wird das aber nicht funktionieren.

Der Product Owner hat auch dafür Sorge zu tragen, dass das Product Backlog immer auf Neuerungen der Product Roadmap abgestimmt und angepasst wird. Es muss ebenfalls immer aktuell gehalten werden und darf keine Inkonsistenz zur Roadmap aufweisen.

Wenn die Roadmap in ihrer ersten Fassung geschrieben steht, werden alle Anforderungen in das Product Backlog überführt und die Epics und Userstorys erstellt.