Städtetour oder Strandurlaub, E-Auto oder doch wieder ein Benziner, die roten oder lieber die schwarzen Schuhe? Entscheidungen fallen vielen Menschen schwer. Den Stakeholdern eines Projekts geht es nicht anders. Speziell wenn festgelegt werden muss, welche Anforderungen mit welcher Priorität realisiert werden sollen. Der verantwortliche Requirements Engineer oder Business Analyst muss diese Entscheidungen herbeiführen. Priorisierungsworkshops mit den Stakeholdern können dabei sehr wirksam und zielführend sein. Sie müssen allerdings gut vorbereitet werden. Hier finden Sie Vorschläge und Tipps dafür. Zunächst:
Um was geht es bei der Priorisierung von Anforderungen?
Mit der Priorisierung wird bestimmt, welche Anforderungen wirklich wichtig sind und damit vorrangig realisiert werden sollten. Das scheint auf der Hand zu liegen. So einfach ist es in der Praxis aber leider nicht. Höchste Priorität hat oft das, was der Stakeholder mit der „lautesten Stimme“, dem stärksten Einfluss oder der größten Nähe zum Management oder Team fordert. Priorisieren heißt, die relative Bedeutung von Anforderungen – verglichen mit den anderen Anforderungen des Backlogs – festzulegen. Zwei Seiten sind dabei abzuwägen:
- der mögliche Geschäftswert, den eine Anforderung schafft, bzw. der Beitrag, den sie zum Erreichen von Geschäftszielen leistet,
- gegen die möglichen Risiken, Implementierungsprobleme sowie ihr Ressourcen-Bedarf.
Warum Workshops?
Unter einem Workshop wird hier ein Arbeitstreffen verstanden, für das der Moderator/die Moderatorin mehrere Techniken im Gepäck hat. Er/sie ist in der Lage, die Techniken situationsgerecht anzuwenden, um Konsens bzw. Kompromisse herbeizuführen.
Welche Techniken gehören ins „Moderatorengepäck“? Die Antwort darauf hängt wesentlich von den Teilnehmergruppen des Workshops ab. Der Business Analysis Body of Knowledge BABOK v3 (vgl. [1]) bietet eine Entscheidungshilfe. Er unterteilt die Priorisierungstechniken in vier Ansätze:
Was steckt hinter diesen Priorisierungstechniken?
Gruppieren
Gruppieren bedeutet das Einteilen von Anforderungen in Gruppen nach einem vorgegebenen Klassifikationsschema.
Bekanntester Vertreter der Gruppierungstechniken ist sicherlich die MoSCoW Priorisierung. Sie wird häufig im Kontext der Release-Planung angewandt. MoSCoW steht dabei für
- M – Must have (unabdingbar, muss umgesetzt werden),
- S – Should have (sollte umgesetzt werden, sofern das nicht zu Lasten der als Must qualifizierten Anforderungen geht),
- C – Could have (kann umgesetzt werden, wenn es die Umsetzung der höherwertigen Anforderungen nicht beeinträchtigt),
- W – Won’t have (kann jetzt zwar nicht umgesetzt werden, ist aber für später vorgemerkt).
(Die Groß-/Kleinschreibung hat keine besondere Bedeutung. Sie soll lediglich die Lesbarkeit verbessern.)
Ein weiteres Beispiel für diese Art der Priorisierung ist die Einteilung von Anforderungen in Rocks, Pebbles & Sand (Felsen, Kieselsteine und Sand). Dieses Klassifizierungsschema ist besonders für die Kommunikation mit dem Produktmanagement bei der Priorisierung von Anforderungen auf einem hohen Abstraktionsniveau – Themen oder Epics – geeignet. Dabei stehen:
- Rocks für schwergewichtige Anforderungen, die etwas bewegen, einen hohen Wert schaffen, z.B. zu entscheidenden Wettbewerbsvorteilen führen,
- Pebbles für Anforderungen, die das Produkt ergänzen, aber nicht für alle Kunden/Anwender hohen Nutzen schaffen,
- Sand für Anforderungen von geringer Bedeutung, die nebenher erledigt werden können, falls Leerlauf oder Wartezeit eintreten sollten.
Rangfolge
Gruppieren ist hilfreich, aber verbunden mit einem Problem. Aus Sicht mancher Stakeholder gilt: Alles muss, nichts kann. Sicher sind Ihnen auch schon Stakeholder begegnet, die nicht akzeptieren wollten, dass nicht alle Wünsche sofort erfüllt werden können. Was also tun, wenn die Gruppe der Anforderungen mit höchster Priorität zu umfangreich geworden ist? Dann müssen Sie mit Ihrer gesamten Überzeugungskraft die Stakeholder dazu bewegen, ein Ranking der hoch-priorisierten Anforderungen vorzunehmen, indem jeder ein entsprechender Rang innerhalb des Backlogs zugeordnet wird.
Time Boxing/Budgetierung
Ist der Lösungsweg bekannt, kann man priorisieren, indem man Fakten schafft. Das ist beispielsweise genau das, was bei der Sprint-Planung passiert, wenn man Anforderungen – d.h. User Stories – nach dem Time Boxing Prinzip in Sprints einplant. Entsprechendes gilt, wenn eine Projektgruppe über ein festes Budget verfügt und Anforderungen auswählt, die im Rahmen dieses Budgets umgesetzt werden sollen.
Aushandeln der Priorisierung
Für den Moderator/die Moderatorin ist der Verhandlungsansatz sicher der schwierigste. Hier geht es darum, Konsens über die Prioritäten herzustellen. Dafür ist es von zentraler Bedeutung, dass dem Workshop eine detaillierte Analyse der Stakeholder, ihrer Beziehungen untereinander, ihrer Motive und Ziele vorausgegangen ist.
Wie hilft Ihnen objectiF RPM beim Priorisieren?
Ein Schwerpunkt von objectiF RPM ist das Requirements Engineering. Das bedeutet: Sie finden in objectiF RPM alles, was Sie brauchen, um
- Stakeholder, ihre Beziehungen und Ziele per Formular und in Diagrammen festzuhalten,
- Anforderungen mit ihren Beziehungen untereinander, aber auch zu Stakeholdern, Zielen und möglichen Risiken vielfältig zu dokumentieren und auszuwerten.
Mit Blick auf die beschriebenen Priorisierungstechniken gilt:
- Für die gemeinsame Priorisierung mit den Stakeholdern finden Sie in objectiF RPM konfigurierbare Backlogs. Sie können sie sortieren, nach Eigenschaften gruppieren und filtern, um einen guten Überblick herzustellen. Für eine detaillierte Ansicht können Sie darin einzelne Anforderungen öffnen und nach Bedarf auch bearbeiten.
- Die Backlogs enthalten bereits einen Mechanismus für das Ranking von Anforderungen: Je weiter eine Anforderung nach oben im Backlog verschoben wird – einfach per Drag & Drop – je höher ihr Rang.
- Eine Gruppierungstechnik ist ebenfalls „eingebaut“: Sowohl im Backlog als auch im Anforderungsformular kann nach MoSCoW priorisiert werden.
Damit können Sie sofort in einem Priorisierungsworkshop „loslegen“. Es sei denn,
- Sie möchten in Hinsicht auf Ihre Teilnehmergruppe die Informationen zu einer Anforderung auf das für die Priorisierung nötigste beschränken. Das könnte sein: die Beschreibung, die Ziele, auf die die Anforderung „einzahlt“ und die erkannten Risiken,
- Sie möchten nicht nach MoSCoW, sondern nach Rocks, Pebbles & Sand vorgehen.
Wie Sie objectiF RPM u.a. mit Hilfe des integrierten Formular Designers entsprechend anpassen, zeige ich Ihnen in diesem kurzen Film.
Das Video zeigt, wie das Ranking mit objectiF RPM funktioniert. Außerdem sehen Sie ein Beispiel dafür, wie Sie in objectiF RPM Backlogs, die darin enthaltenen Gruppierungstechniken sowie Formulare optimal auf Ihre Priorisierungsworkshops und den Bedarf Ihrer Teilnehmergruppen zuschneiden können
Die Möglichkeiten zur Anpassung von objectiF RPM sind vielfältig. Schauen sie sich das doch einmal aus der Nähe an – mit der kostenlosen Trial-Edition von objectiF RPM.
Ihnen wird nicht entgangen sein, dass zwei Priorisierungsansätze in der näheren Betrachtung noch fehlen. In meinem nächsten Beitrag wird es um das Thema Fakten schaffen bei der Priorisierung durch Time Boxing gehen bzw.– etwas weiter gefasst – um das Durchführen von Planungsworkshops.
Quelle:
[1] BABOK v3 Leitfaden zum Business Analysis Body of Knowledge®, IIBA® International Institute of Business Analysis™, deutsche Ausgabe, Verlag Dr. Götz Schmidt, Gießen 2017