Gespeichert von Christoph Mathis am Do, 04/08/2010 - 17:35

Kein Projekt (oder Unternehmen) ohne Priorisierung kann erfolgreich gesteuert werden. In einem agilen Projekt kann man auf auftretende Änderungen zeitnah reagieren. Damit das auch funktioniert,

  • Muss der Product Owner nützliche Abstraktionen haben – sowohl um über einzelne Produktfeatures zu entscheiden als auch um den Projektfortschritt effektiv zu überwachen. Aus diesen beiden Anforderungen können durchaus verschiedene Sichtweisen entstehen.
  • Muss der Product Owner tiefer in der Arbeit des Teams eingebunden sein als ein traditioneller Projektmanager. Da er im Prinzip gleichzeitig mit dem Team arbeitet,  hat er wesentlich bessere Möglichkeiten einzugreifen und neue Erfahrungen aufzunehmen.

Priorisierung des Product Backlog durch den Product Owner 

  • Steuert effektiv den Produktzuschnitt und den Arbeitsfortschritt
  • Muss zugeschnitten sein auf die Aufgabe das Team auf die wichtigsten Arbeiten zu fokussieren, 
  • Schützt das Team vor permanentem Entscheidungsstress

Es gibt einen Unterschied zwischen Portfolio-Planung und PBL – deshalb funktioniert es nicht, einfach die Priorisierungsmethoden der Portfolioplanung zu übernehmen.

Priorisierungen für das Portfolio

Für die Portfolioplanung gibt es verschiedene etablierte Priorisierungsverfahren: ROI, NPV, Kano, Theme screening und viele andere.

Alle diese bestimmen eine Kennzahl aus der BWL, die Gewinn oder Kosten auf einzelne Einträge herunterbricht. 

Mit diesen Verfahren werden die potientiellen Features des Produkts bewertet und validiert. Dann stellt man die Features zusammen, die in die einzelnen Releases aufgenommen werden.

Dummerweise funktioniert das nicht so einfach für einen Prouct Backlog. Die Verfahren sind entweder viel zu aufwändig, um belsatbare Zahlen für die einzelnen Einträge zu bestimmen und/oder die Sinnhaftigkeit geht beim Herunterbrechen auf einzelne Einträge verloren.

Es kann sogar gefährlich sein, Kriterien zu haben, deren breite Anwendung schwierig oder nicht möglich ist, z.B.: für Einzelfälle: ein Kunde zahlt x € für ein Feature, es kostet y € und x >= y: manchmal tun wir das auch, wenn x < y ist (weil wir den Kunden mögen, weil wir das Geld brauchen, ...) oder weil es die einzigen Features sind, für die wir überhaupt Zahlen haben.

Zum Priorisieren des Product Backlog muss der Product Owner eine Gruppe von geeigneten pragmatischen Attributen entwickeln, an denen er die zu priorisierenden Einträge bewertet und sortiert

Es ist im besten Fall sehr aufwändig, den ROI einzelner Backlog-Stories festzustellen. Die meisten Stories in einem Backlog, die detailliert genug zum Realisieren (“ready”) sind, haben keinen eigenen ROI.

ROI-basierte Priorisierung ist eine Sackgasse: Wir müssen andere Attribute für eine PBL-Priorisierung finden

Ein Prozess für die Priorisierung

Wir brauchen also einen spezifischen Prozess für die Priorisierung, der das Spannungsfeld zwischen der Sicht des Gesamtprodukts und der Sicht der Abbildung in Sprints berücksichtigt.

Danach werden die Elemente des Backlog so sortiert, dass sie optimal zu den Gewinntreibern beitragen.

Das umfasst die folgenden Schritte:
  • Identifiziere Schlüsselattribute
  • Gruppiere sie
  • Entwickle eine Gewichtung
  • Priorisiere den Backlog

Der Schlüssel für Priorisierung nach Gewinn ist:

  • Gleiche Anforderungen der Stakeholder aus
  • Synchronisiere mit der Unternehmensstrategie
  • Bediene die Gewinntreiber

Mögliche Attribute für die PBL-Priorisierung

Speziell: Attribute, die einem Team erlauben, nach Gewinn zu priorisieren

Ablauf:

  • Identifiziere eine Menge von Attribute, die Backlog-Items zugeordnet werden
  • Weise den Attributen einen Wert zu
  • Bestimme die Gewichtung
  • Sortiere die Backlog-Items

Kandidaten für Attribute

  • Kunden-Präferenzen, gewonnen aus den Marktuntersuchungen
  • Kosten-basierte finanzielle Attribute, die als Nebeneffekte der agile Schätzrunden entstehen
  • Bewertungen interner Stakeholder (Vertrieb, Services, Entwicklung)
  • Firmen-Prioritäten, z.B. die Präferenz, einen neuen Markt zu entwickeln oder die Effektivität zu erhöhen
  • Abhängigkeit von externen Systemen (vor allem, wenn diese nach einer Wasserfall-Methode entwickelt werden)
  • Verschiedene Risiko-Attribute wie technische oder Markt-Risiken
  • Weitere Attribute, die den Gewinn beeinflussen

Auswahl und Gewichtung der Attribute

Auswahl und Gewichtung der Attribute zur Priorisierung variieren mit dem Produkt und z.T. mit dem Release. Gleichzeitig reflektieren sie die Denkweise des Product Owners. 

Ein Standard-Satz von Attributen trägt zur Übersichtlichikeit und zum effektiven Arbeiten des Product Owners bei:

  • Sie gelten über mehrere Releases
  • Ihr Wert kann einfach und kostengünstig bestimmt werden
  • Sie unterstützen ein effektives Produkt-Management
  • Sie sind konsistent mit den Firmen- und Produktzielen

Kriterien für die Attributauswahl

In aller Regel sind erfüllen die folgenden Gruppen diese Kriterien:

  • Stakeholder Präferenzen (Stakeholder gibt es als interne und externe Stakeholder)
  • Konsistenz mit den Unternehmenszielen
  • Treiber für den Gewinn

Es wäre schön, wenn man direkte Marktforschung zu den User Stories treiben könnte, aber auf dieser Detaillierungsebene ist das in aller Regel zu aufwändig.

Stakeholder Präferenzen

Interne Stakeholder

  • Vertrieb
  • Marketing
  • Kundenservice
  • IT und Maintenance

Sie sind wichtig für den Projekterfolg, weil sie die Funktionen der Firma repräsentieren, die für den Kunden funktionieren müssen.

IT und Maintenance müssen berücksichtigt werden, auch und gerade weil sie oft in Konflikt mit den kurzfristigen Wünschen nach Weiterentwicklung stehen. Ein wichtiger interner Stakeholder ist das „System“.  Es muss gewartet werden, deshalb muss eine gute Qualität der Architektur und des Codes eingebaut werden. Manche Teams verwenden es direkt: ?„Als System will ich ... damit ...“

Externe Stakeholder

  • Kunden
  • Marketing-Partner
  • Distributoren
  • Die ganze Community, die mit dem Produkt verbunden ist

In aller Regel werden diese Stakeholder (auf der Ebene der User Stories) indirekt über Einschätzungen des Product Owners oder interner Stakeholder gehört.

Konsistenz zur Firmenstrategie

Der Product Owner muss aktiv mit dem Management arbeiten, um die Konsistenz der Kriterien und Prioritäten mit der Firmenstrategie herzustellen und kontinuierlich zu kommunizieren und zu überprüfen. Wenn er das versäumt, provoziert er geradezu Spannungen und Eingriffe bis zum Mikro-Management des Projekts / der Produktentwicklung.

Prioritize for Profit ?

Jeder Product Owner sollte (erfolgreiche PO können das fast immer) beantworten können, wie eine User Story zu profitablem Wachstum beiträgt. Achtung: diese Attribute beschreiben keine isolierten Verbesserungen des Produkts, sondern die Zuordnung zu den Profit-Treibern des Geschäfts:

  • Geringere Kosten
  • Verkäufe im Luxus-Segment ...

In der Verbindung der User Stories und den Profit-bezogenen Attributen liegt die Schlüssel-Verbindung zwischen den Rollen eines Product Owners und eines voll verantwortlichen Agilen Produkt-Managers

Driving Profit - Fragen

  • Was ist Ihr value-exchange-Modell
    • Zeitbasierter / dauerhafter Zugriff auf Software
    • Transaktionsbasiert (z.B. Kreditkarten-Formen)
  • Wie ist Ihre Beziehung zum Markt
  • Was treibt Ihren Gewinn

Zum Beispiel 

  • Adobe: kostenloser Reader, der den Markt für weitere PDF-basierte Produkte bereitet
  • Kreditkartenfirmen, die ein umfassendes Netzwerk mit Standardisierung, Sicherheitsfunktionen etc. zur Verfügung stellen

Der Priorisierungsprozess

  • Sammle die Präferenzen der Stakeholder
  • Synchronisiere mit der Unternehmensstrategie
  • Treiber für den Gewinn
  • Bestimme die Daten für die Priorisierung

Sammle die Präferenzen der Stakeholder

  • Gewinne ihre Perspektive auf die User Stories
  • Beteilige sie kontinuierlich, finde Alternativen zu traditionellen Marktuntersuchungen
  • Benutze neue Werkzeuge um zu neuem Denken zu gelangen
  • Beteilige sie an Innovation Games, um Vorstellungen und Priorisierungen zu ermitteln (z.B. buy-a-feature)

Dabei kann die System-Perspektive auf der Strecke bleiben. Das muss man aktiv kompensieren, z.B. indem man „dem System“ eine eigene Stimme gibt

Synchronisiere mit der Unternehmensstrategie

Wenn die Strategie klar ist (das ist der einfache Fall)

  • Setze sie in Attribute zur Bewertung der User Stories um
  • Zeige, für welche User Stories sie zutreffen
  • Übernimm wenigstens einige in den Backlog

Wenn das schwierig ist - z.B. wegen einer unklaren Strategie

  • Folge der bestmöglichen Interpretation
  • Arbeite mit dem Management an Strategie und Marktforschung
  • Manchmal ist es richtig, die Strategie zu ändern
  • Demonstriere die Konflikte von User Stories
  • Verhandle mit dem Management

Driving Profit

Hinterfrage, ob Kunden ein Feature einfach nur erwarten oder ob es wirklich ein Gewinntreiber ist.

Ein Produkt muss letztlich profitabel sein, und es ist Verantwortung des Product Owners zu zeigen, welche User Stories den Gewinn treiben

  • Aus Sicht des value-exchange-Modells
  • In der Beziehung zum Markt

Der Konflikt bleibt zunächst: User Stories, die als Gewinntreiber identifizierbar sind, tendieren dazu, groß zu sein (Epics). User Stories, die in einen Sprint Backlog eingehen, müssen oft viel kleinteiliger sein. Das ist OK, wenn die Beziehung transparent, für das Team nachvollziehbar ist und damit der Fokus der Arbeit klar bleibt.

Test 1: Stakeholder Balance

Ein ausgeglichener Backlog hat in jedem Release mindestens eine User Story für jeden Stakeholder.

Durch unausgeglichene Releases verlieren wir am Ende Kunden, Stakeholder, Channel Partner ... oder den guten Willen interner Stakeholder

Test 2: Synchronisierung mit der Unternehmensstrategie

Ein strategisch synchronisierter Backlog hat in jedem Release mindestens eine User Story, die direkt mit den Schlüsselelementen der Unternehmensstrategie korreliert werden kann

Test 3: Profit

Ein Backlog treibt den Gewinn für einen Release, wenn mindestens eine User Story kongruent mit dem value-exchange Modell ist und den Gewinn treibt

Quellen

Brandon Carlson: Story prioritization at the Blink of an eye - blog.projectconnections.com/project_practitioners/2008/09/story-prioritiz.html 

Pascal Van Cauwenberghe: Whose value is it anyway? - blog.nayima.be/2010/01/06/whose-value-is-it-anyway/ 

Pascal Van Cauwenberghe: How do you estimate the Business Value of User Stories? You don’t. blog.nayima.be/2009/12/30/how-do-you-estimate-the-business-value-of-user-stories/ 

Mike Cohn: Prioritizing your Product Backlog - Agile 2009 conference -  www.mountaingoatsoftware.com/presentations/108-prioritizing-your-product-backlog 

Mark Denne, Jane Cleland-Huang: Software by Numbers - Prentice Hall 2004

Luke Hohman: Why Prioritizing Your Product Backlog for ROI Doesn’t Work - http://www.enthiosys.com/insights-tools/prioritizeforprofit1of3  (and part 2 and 3)