Der Fahrplan – Roadmaps für Produktentwicklung

Der Fahrplan – Roadmaps für Produktentwicklung

Aufbau einer Roadmap für agile Produktentwicklung

Keine Frage, die Aufgabe des Product Owners ist es, das Backlog des Produkts zielgerichtet mit qualifiziertem Story-Nachschub zu versorgen und auf dem neuesten Stand zu halten. So führt er das Entwicklungsteam in eine klar erkennbare Richtung. Aber: Ideen, Anforderungen und Rahmenbedingungen aus allen Richtungen weisen eigentlich immer unterschiedliche Ziele und Mehrwerte auf. Ohne klare Ziele wird es schwer, sich auf das Wichtigste zu fokussieren – dem Team fehlt der rote Faden und eine Verbindung zum Produkt. Eine Product-Roadmap ermöglicht die Fokussierung auf Releases die jeweils ein eindeutiges Ziel mit einer Menge von Features verfolgen.

Ich stelle hier ein Format für Workshops vor, mit dem Product Owner gemeinsam mit Stakeholdern und Entwicklungsteam Releases zusammenstellen und priorisieren, so dass sich daraus eine Roadmap ergibt.

Der Product Owner ist für das Management der Roadmap im Lead und trifft Entscheidungen basierend auf Konsens, Konsent oder – wenn keine Einigung möglich – begründet alleine. Teilnehmer sind wichtige Stakeholder und einzelne Mitglieder aus dem Entwicklungsteam. “Wichtige Stakeholder” ist natürlich eine stark auslegbare Bezeichnung: Relevante Teilnehmer sind Players, also solche die ein großes Interesse am Produkterfolg haben und über viel Einfluss verfügen. Bei vielen Teilnehmern empfiehlt sich ein Moderator. Verfügt man noch nicht über eine Roadmap, so nimmt man sich für den Workshop am besten vier Stunden Zeit. Nimmt man ein Update vor, reichen ein bis zwei Stunden. Benötigt wird das übliche Moderationsmaterial (viele Post-Its und Stifte), sowie ein Flipchart und viel Platz an Wänden.

Das Ziel

Der Workshop wird fachliche Featurewünsche der Stakeholder qualifizieren und in eine priorisierte Reihenfolge bringen. Der Plan für die nächsten Monate ist danach aus einer größeren Flughöhe erkennbar. Alle ziehen gemeinsam an einem Strang und rücken in dem Verständnis was auf alle zukommt näher zusammen. Weder Stakeholder noch Product Owner vermitteln den Eindruck, dass jeder seine eigenen Interessen verfolgt. Die Roadmap ist nach Releases aufgeteilt. Bei einem Release für die Roadmap kann es sich um große neue Features einer Website, Kampagnen, einen Relaunch usw. handeln – fachlich weitestgehend in sich geschlossen. Jedes Release wird in einen Steckbrief gegossen, der Ziel, Features und Messmetriken (wie stellen wir fest, dass das Ziel erreicht wurde?) darstellt. Dafür verwende ich das  Template “GO PRODUCT ROADMAP” von Roman Pichler.

Das Template “GO Product Roadmap” von Roman Pichler – http://www.romanpichler.com/tools/product-roadmap/

Vorbereitung für den Workshop

Die vielen Ziele, Ideen und Pläne der Stakeholder sollten für den Workshop vorbereiten werden. Zwar arbeiten wir im Workshop gemeinsam an Formulierungen, Bewertungen und Priorisierung, aber insbesondere für die erste Durchführung des Formats ist die Vorqualifizierung durch den zuständigen Stakeholder wichtig. Am besten gibt der Product Owner den Stakeholder vorab eine Hausaufgabe mit. Es sollen mittelgroße Featuregruppen mit vier Eigenschaften vorbereitet werden:

  • NAME? – Wie lässt sich die Featuregruppe griffig benennen?
  • WAS / Features? – Welche prägnanten Features aus fachlicher Sicht? Hier grob und nicht zu fein denken.
  • WANN / Zieltermin? – Wann muss die Featuregruppe live gehen (aufgrund von Rahmenbedingungen). Dieses Datum ist optional und sollte eher selten verwendet werden.
  • WARUM / Mehrwert? – Welchen Mehrwert bringt die Featuregruppe für Kunden? Welche Probleme / Bedürfnisse werden adressiert? Was bringt es der Firma?
  • WIE MESSEN / Messbare Ziele? – Wie kann man feststellen, ob Features erfolgreich sind? Welche KPIs sind dafür geeignet?

Sinnvoll hierfür ist ein Vorbereitungstermin mit klaren Beispielen und der Vorstellung vom Ablauf des Workshops. Ist das Vorgehen für alle Beteiligte noch neu oder sind die Stakeholder noch nicht geübt im Formulieren von Anforderungen. empfehle ich dem Product Owner, im Vorfelde intensiv zu unterstützen. Insbesondere das Finden von Metriken / KPIs zur Erfolgsmessung fällt vielen sehr schwer.

Der Product Owner legt vor dem Workshop die Länge des Umsetzungszeitraums für ein Release fest. Je nach Dynamik des Marktes und Reifegrad des Produkts sollte in Monaten oder Quartalen geplant werden.

Schritt 1: Sammeln

Im Workshop sammeln wir zunächst pro Featuregruppe zu den Eigenschaften “Name”, “Features”, “Zieltermin” und “Mehrwert” Input. Dafür wird vor dem Workshop ein Satz von Flipcharts (10-12) vorbereitet, in die jeweils drei Zeilen mit der entsprechenden Beschriftung gezeichnet wird. Pro Eigenschaft gehen wir eher in die Breite und sammeln Input. Ein Stakeholder fängt für eine Featuregruppe an und füllt das Flipchart mit Post-Its. Die anderen Stakeholder ergänzen, alle stellen und beantworten Verständnisfragen. Product Owner und – wenn vorhanden – Moderator haben ein besonderes Augenmerk darauf, dass Inhalt und Mehrwert eindeutig sind. Das hilft allen zur späteren Bewertung. Sinnvoll ist auch, zu schneiden. Hier helfen Erfahrung und Bauchgefühl: Wenn eine Featuregruppe sehr komplex oder als Ganzes zu riskant erscheint, sollte sie lieber zerteilt werden. Als Faustregel gilt, dass Featuregruppen etwas größer als Epics sein sollten.

flip_mit_post

Pro Featuregruppe füllen wir einen Flipchart aus.

Pro Featuregruppe plane ich maximal 15 Minuten ein. Insgesamt reicht eine Timebox von 120 Minuten. Am Ende sollten alle Flipcharts zwecks besserer Übersicht an der Wand hängen oder auf dem Boden liegen.

Schritt 2: Priorisieren – Was ist am wichtigsten?

Anhand von Features, Mehrwert (hier liegt der Schwerpunkt) und Zieltermin (nur wirklich relevant, wenn aus festen Rahmenbedingungen hervorgegangen ist) diskutiert die Gruppe nun, um die Featuregruppen in eine priorisierte Reihenfolge zu bringen. Dafür hat sich bewährt, in fester sich wiederholender Reihenfolge einen Stakeholder nach dem anderen ausgefüllten Flipcharts  so lange umhängen zu lassen, bis es einen Konsens gibt oder eine Timebox verstrichen ist. Es ist immer nur ein Teilnehmer an der Reihe, es darf nur ein Flipchart umgehängt werden und jede Aktion muss begründet sein. Die Begründung und Diskussion erfolgt nach Kosten-Nutzen-Verhältnis.

Für den Nutzen gilt:

  • Welchen Mehrwert schafft das Feature für den Nutzer?
  • Welchen Mehrwert schafft das Feature für die Firma?
  • Welche KPIs werden dadurch in welcher Weise beeinflusst?

Um die Kosten einzuschätzen, ziehe ich folgendes heran:

  • Wie komplex ist die Umsetzung des Features?
  • Welche Risiken birgt das Feature?
  • Ist das Feature eher ein Randfeature?
features_prio

Die Featuregruppen werden in eine priorisierte Reihenfolge gebracht.

Hierfür plane ich eine Timebox von 60 Minuten ein.

Schritt 3: Releases schneiden

Nun gilt es, die Featuregruppen in Releases zu gießen. Featuregruppen können zusammengelegt oder zu einem Release gemacht werden. Die Fragestellung dabei: Was gehört thematisch eng zusammen oder lässt sich gut zusammenlegen? Wie viel lässt sich in dem Umsetzungszeitraum des Releases ehrlicherweise umsetzen?

Danach werden die Releases nach Priorität sortiert. Das Release mit den wichtigsten Featuregruppen sollte auch an erster Stelle stehen. Die Gruppe konzentriert sich auf die wichtigsten vier Releases. Jedes Release muss realistisch erreichbar sein und auch ausreichend Puffer für neue Anforderungen aufweisen. Der Product Owner führt in dieser Phase alleine oder mit Hilfe des Moderators eine Einigung herbei oder trifft bei Uneinigkeit eine begründete Entscheidung.

Am besten eine Timebox von 30 Minuten anwenden.

Schritt 4: Was ist das Ziel und wann sind wir erfolgreich?

Pro Release ist es nun wichtig, gemeinsam festzulegen, was das Ziel ist und wie der Erfolg gemessen wird. Das Ziel soll allen dabei helfen, sich zu fokussieren. Das ergibt sich recht schnell, wenn man sich die wichtigsten Features des Releases vor Augen führt. Das Ziel hilft auch dabei, Pflicht-Features von optionalen Features zu trennen. Beispielsweise kann ein Ziel lauten, dass in einem Shop Gutscheine gezielt an Kunden verteilbar und für den Kauf einlösbar sind. Daraus ergeben sich dann Pflicht-Features, deren Umsetzung genau auf dieses Ziel einzahlt. Optional können für dieses Release dann noch Features für die Überarbeitung des Seitenlayouts für Kreditkartenzahlung.

Wichtig sind zudem Metriken / KPIs, die für die Zielerreichung herangezogen werden. Auf diese einigt man sich, um den Erfolg der Arbeit zu messen. Die relevanten KPIs zu finden ist gar nicht so einfach. Der Einsatz von sogenannten Vanity Metrics (wie Website-Hits) ist verführerisch, sagt aber wenig über den Erfolg aus. Gute Beispiele für Metriken sind:

  • Steigerung des Umsatzes um 5% bis zum 30.6.2016
  • 6000 Neuregistrierungen im Zuge der Marketing-Aktion bis 11.2.2016
  • 10.000 vergebene Gutscheine und der damit verbundene Mehrumsatz von 120.000€ in den nächsten sechs Monaten nach Livegang

Ich plane hierfür eine Timebox von 60 Minuten ein. Am besten arbeitet man mit Post-Its, so dass man diskutieren, überlegen und umformulieren kann.

Schritt 5: Steckbrief ausfüllen

Ist man sich einig, werden die Releases in den Steckbrief übertragen. Relevant sind hierfür nur die ersten vier, weiter lohnt sich nicht zu planen. Vor der Übertragung muss die Gruppe pro Release jeweils die Essenz von GOAL, FEATURES und METRICS finden. Dabei darf gerne umformuliert und ergänzt werden.

Schritt 6: Release-Datum festlegen

Der nächste Schritt ist in der Regel einfach. Je nach Länge eines Release-Zeitraums (1-3 Monate), wird das Datum / der Monat / das Quartal in das entsprechende Feld eingetragen. Ich führe dies als eigenen Schritt auf, weil es hier durchaus noch zu Diskussionen kommen kann.

Ich plane hierfür eine Timebox von 10 Minuten ein.

Nach dem Workshop

Aus dem Workshop nimmt der Product Owner den Entwurf der Roadmap mit und konsolidiert (z.B. Formulierungen schärfen) sie im Nachgang. Danach ist die Vorstellung von bisher unbeteiligten Team-Mitgliedern und Stakeholdern wichtig (“Das haben wir in den nächsten Quartalen vor!”, “Was haltet ihr davon?”). Schließlich nutzt der Product Owner die Roadmap um gezielt Stories dafür zu schreiben und gezielt Discoveries zu starten. Das ist übrigens ein wichtiger Punkt, der in der Praxis immer wieder vernachlässigt wird: Roadmap und Backlog arbeiten Hand in Hand und beeinflussen sich gegenseitig.

Die Roadmap wird bei Bedarf überarbeitet. Ich empfehle sie immer dann zu überprüfen, wenn die ersten Releases umgesetzt, der Erfolg von Releases validiert oder neue Erkenntnisse aus Daten gewonnen wurden. Überprüfungen mit optionalen Anpassungen kann man monatlich oder quartalsweise durchführen. Als Faustregel gilt: Je jünger das Produkt und je frischer der Einsatz der Roadmap, desto kürzer sollten die Überprüfungszyklen sein.

Wichtig ist, die Metriken der Ziele nach erfolgreichem Release zu messen. Die Messung findet während des nächsten Releases statt. Wurde ein Ziel nicht erreicht, so wird dies zur nächsten Roadmap-Überprüfung transparent gemacht und kann zur Anpassung der Roadmap führen. Bei der Messung der Zielerreichung unterstützt der ScrumMaster oder Coach tatkräftig.

Fazit

Der Workshop hilft Product Owner, Entwicklungsteam und Stakeholdern die Weiterentwicklung des Produkts gemeinsam abzustecken – vor allem initial. Arbeitet der Product Owner mit mehreren Stakeholdern aus unterschiedlichen Bereichen, so entwickeln alle ein gemeinsames Bild von der Wichtigkeit und Reihenfolge von Releases. Das Team bekommt ein klares Bild darüber, wohin die Reise geht.

Vorbereitung auf intensive Diskussionen ist hilfreich. Schließlich hängt an Featurewünschen auch Herzblut oder Organisations-Druck. Ich empfehle für die ersten Roadmap-Versionen daher lieber einige wenige Releases zu planen und kürze Überprüfungszyklen zu wählen.

Image:
Diesen Artikel teilen:

Einen Kommentar hinterlassen

*

1 comment

  1. Pingback: Projektpfad – Der Blog für agile Produktentwicklung – Das fokussierte Backlog

Projektpfad – Der Blog für agile Produktentwicklung - Background

Suche eingeben

Alle Ergebnisse anzeigen