Fragestellung

Wie priorisiert ihr Projekte im Portfolio bzw. Features im Projekt?

Ausgangssituation

Es gibt nicht den einen Kunden/Auftraggeber, der die Priorisierung vorgibt, sondern mehrere Kunden, die euer IT-Produkt nutzen und sich neue Features wünschen. Eine Priorisierung nur auf Basis des Aufwands ist unzureichend. Dann werden evtl. Features implementiert, nur weil sie wenig Aufwand kosten, aber evtl. auch wenig Nutzen bringen. Ein Einwand ist immer, dass der Nutzen nur subjektiv einschätzbar ist und evtl. nicht der Realität entspricht. Nun so ist auch die Aufwandsschätzung und sogar die Planung - und man macht sie trotzdem.

Session-Format

Workshop. Alle stellen ihre bevorzugten Priorisierungsmethoden bzw. Methoden um Nutzen einzuschätzen vor. 

Priorisierungsmethoden

Business Value Poker

Spiel für Product Owner und Stakeholder (idealerweise sind dabei auch Endkunden vertreten). Jedes Feature wird gepitched und dann nach folgenden 4 Dimensionen mithilfe von Karten von 100 bis 3000 Punkten bewertet:

  • Neukunden
  • Upsellpotential
  • Wartung und operative Kosten senken
  • Kunden, die kündigen würden, wenn das Feature nicht umgesetzt wird.

Wie beim Planning Poker werden große Unterschiede in der Bewertung besprochen.

Danach können die Features in den einzelnen Quadranten im folgenden Bild dargestellt werden und umgesetzt.

Buy a feature

Plattformen, auf welchen die Kunden für einzelne Features "voten" können oder Workshops, bei denen jeder Kunde z.B. 100$ bekommt und damit Features kaufen kann.

Magic Prioritization

Den Namen haben wir ausgedacht, analog zu Magic Estimation. Die Features werden besprochen und nach ihrer Prio sortiert. Falls es unterschiedliche Einschätzungen zu der Prio gibt, werden diese besprochen.

Priorisierung auf unterschiedlichen Ebenen

Tasks (1 Tag) auf Team-Ebene priorisieren, Features - auf Programmebene, Projekte - auf Portfolio-Ebene

ROI

ROI anhand von Zeitersparnis für Nutzeraktionen im System anhand von Keystroke-Level-Model sowie Daten zum Nutzerverhalten berechnen. 

Weitere Anregungen

Achtung: Confirmation Bias

Oft hat man ein Gefühl, wie wichtig ein Feature ist und sucht solche Daten, die sein Gefühl bestätigen

Kunden fragen

Auch einen - und noch besser fünf - Kunden zu fragen ist besser als Features anhand von eigenen Annahmen über Prioritäten aus Kundensicht zu priorisieren.

Projekte klein schneiden

Das kleinste nutzenbringende Feature releasen

Kein Projekt ist länger als 3 Monate

Weitere Links zum Thema

20 Product Prioritization Techniques

Zu Buy a feature: http://www.innovationgames.com/buy-a-feature/ bzw. Buch "Innovation Games" von Luke Hohmann

Twittern
  • No labels

Dieser Inhalt von openPM steht unter einer Creative Commons Lizenz (CC BY 3.0) und kann frei verwendet werden unter Namensnennung durch Link auf http://openpm.info. Unpassende Inhalte, insbesondere Verstöße gegen Urheberrechte, bitte via info@openpm.info melden. Weitere Informationen unter Nutzungsbedingungen