Gerade wenns um die Priorisierung geht, sieht man oft noch klassische Muster. Muster im Sinne von ich bin der Auftraggeber und ich sage euch, was ihr wann zu tun habt.
Soviel vorweg: Eine Priorisierung ist dann sinnvoll, wenn alle notwendigen Informationen herangezogen werden, um die Priorisierung vorzunehmen. Eine einzige Person ist nur bei simplen Projekten in der Lage vollständige Information zu besitzen und damit die Arbeitspriorisierung alleine vorzunehmen. Sobald die Vorhaben komplexer werden, sind die Inputs von möglichst vielen relevanten Stakeholdern sinnvoll. Das heisst nun nicht, dass der PO nicht das letzte Wort hat bei der Priorisierung des Product Backlogs. Das hat er auf jeden Fall. Vielmehr sollen alle Teammitglieder des Scrum Teams ihre Informationen einbringen, sodass eine abgewogene Priorisierung gemacht werden kann.
Auch in skalierten Setups, wo es neben dem PO noch weitere Rollen gibt, die über Produktverantwortung verfügen (bspw. ein Produkt Manager), sollte eine Priorisierung stets im Team gemacht werden. Vielleicht nicht mit allen Mitgliedern aller betroffenen Scrum Teams, sondern in einem dedizierten Product Team wo der Product Manager, die Product Owners, die Business Analysten, die tech. Leads und weitere wichtige Stakeholder partizipieren. Nur so kann sichergestellt werden, dass alle Informationen berücksichtigt werden.
Ein Produkt Manager beliefert zwei Scrum Teams mit Anforderungen. Gleichzeitig existiert vielleicht ein Enterprise Architekten Team, welches auch Anforderungen von den Scrum Teams umgesetzt haben möchte. Abgesehen davon, dass dieser Setup nicht dem Ideal entspricht, trifft man ihn leider doch noch häufig an.
Damit das Produkt nun nachhaltig entwickelt werden kann, müssen beide Anforderungsquellen gleichermassen einfliessen. Die Vertreter der Anforderungsquellen (PM und Enterprise Architekt) sollen ihre Anforderungen erläutern, um Verständnis bei den anderen Teammitgliedern zu erzeugen. Vielleicht hat daraufhin ein tech. Lead auch noch den einen oder anderen ergänzenden Input aus technischer Sicht oder ein PO gibt Bedenken, was Abhängigkeiten zu anderen Scrum Teams angeht etc. Nur mit der Abwägung aller Inputs schafft es ein Produkt Team eine wirkungsvolle Priorisierung zu erstellen und damit das Produkt nachhaltig zu gestalten. Wie beim vorhergehenden nicht-skalierten Setup soll eine Person (hier vielleicht der PM) das letzte Wort haben.
Oft sehen wir, dass für die Priorisierung von Anforderungen Bewertungsmethoden verwendet werden. Ein Beispiel ist WSJF (Weighted Shortest Job First) welches von Donald G. Reinertsen in "The Principles of Product Development Flow: Second Generation Lean Product Development" entwickelt wurde und im Scaled Agile Framework Verwendung findet. Daran ist grundsätzlich nichts Verwerfliches. Eine Bewertungsmethode ist aber nur dann sinnvoll, wenn die Bewertung wiederum gemeinsam im Team gemacht wird. Ansonsten werden automatisch subjektive Bewertungsskalen herbeigezogen, die nicht vergleichbar sind. Wiederum an unserem obigen Beispiel veranschaulicht: wie sollen die Faktoren aus WSJF wie zum Beispiel Business Value oder Risk Reduction vergleichbar sein, wenn der PM und der Enterprise Architekt jeweils in ihren separaten stillen Kämmerlein eine subjektive Bewertung ihrer eigenen Anforderungen vornehmen? Da hilft auch kein Referenz-Epic.
WSJF ist eine Formel, mit der der "Cost of Delay" berechnet werden kann. Also die Kosten die man tragen muss, wenn eine Anforderung zu spät umgesetzt wird. Die Idee dahinter ist es, sehr heterogene Anforderungen vergleichbar zu machen, damit sie gegeneinander abgewogen werden können.
Die detaillierte Beschreibung zur Formel gibts hier.
Willst du mehr darüber erfahren, wie man priorisiert und ganz generell wie man ein Backlog managed? Dann komm an einen unserer Agile RE Kurse mit geballter Praxiserfahrung.
Keine Kommentare bis jetzt
Lass uns wissen, was du darüber denkst.