Warum müssen Anforderungen priorisiert werden?
Budget, Zeit und Kapazität reichen fast nie für alle Wünsche. Priorisierung entscheidet, welche Anforderungen zuerst umgesetzt werden, welche später und welche möglicherweise gar nicht. Der IREB-Lehrplan beschreibt Bewertung und Priorisierung als Mittel, um die relevantesten Anforderungen für das nächste Release oder Inkrement zu bestimmen; die Priorität einer Anforderung beschreibt ihre Bedeutung im Verhältnis zu anderen Anforderungen nach bestimmten Kriterien [1].
Ohne bewusste Priorisierung setzen sich die lautesten Stimmen durch, oder das Team arbeitet nach der Reihenfolge des Eingangs. Beides führt dazu, dass wertvolle Anforderungen zu spät oder gar nicht umgesetzt werden. Eine nachvollziehbare Priorisierung schafft zudem Akzeptanz bei Stakeholdern, deren Wünsche nicht sofort erfüllt werden, weil sie die Gründe kennen.
In welchen Schritten läuft die Priorisierung ab?
- 1Wichtigste Ziele und Randbedingungen der Priorisierung festlegen, etwa ein Release mit festem Termin.
- 2Gewünschte Bewertungskriterien definieren, etwa Geschäftswert, Dringlichkeit, Risiko und Aufwand.
- 3Festlegen, welche Stakeholder beteiligt werden.
- 4Festlegen, welche Anforderungen priorisiert werden, möglichst auf gleicher Abstraktionsebene.
- 5Priorisierungstechnik wählen.
- 6Prioritäten festlegen und dokumentieren.
Diese sechs Schritte stammen aus dem IREB-Lehrplan [1]. Der vierte Schritt wird oft unterschätzt: Werden grobe Ziele und detaillierte Anforderungen gemeinsam priorisiert, entstehen unsinnige Vergleiche. Bewährt hat sich, zuerst übergeordnete Anforderungen zu priorisieren und danach die Details innerhalb der wichtigsten Bereiche.
Nach welchen Kriterien wird bewertet?
| Kriterium | Leitfrage | Wer bewertet typischerweise |
|---|---|---|
| Geschäftswert | Welchen Nutzen bringt die Anforderung für Organisation oder Kunden? | Auftraggeber, Fachbereich, Product Owner |
| Dringlichkeit | Was geschieht, wenn sie später umgesetzt wird? | Fachbereich, Auftraggeber |
| Risiko | Welches Risiko reduziert die Umsetzung, etwa technisch oder rechtlich? | Architektur, Sicherheit, Recht |
| Aufwand | Wie aufwendig ist die Umsetzung? | Entwicklungsteam |
| Abhängigkeiten | Setzen andere Anforderungen diese voraus? | Team, Requirements Engineer |
| Rechtliche Pflicht | Ist sie gesetzlich oder vertraglich vorgeschrieben? | Recht, Compliance |
Der Lehrplan nennt als Beispiele Geschäftswert, Dringlichkeit, Aufwand und Abhängigkeiten [1]. Rechtliche Pflichten nehmen eine Sonderrolle ein: Sie werden meist nicht gewichtet, sondern gesetzt. Eine gesetzlich vorgeschriebene Anforderung steht nicht zur Disposition, unabhängig davon, wie gering ihr Geschäftswert scheint.
Welche Priorisierungstechniken gibt es?
| Technik | Kategorie | Vorgehen | Geeignet für |
|---|---|---|---|
| Rangfolge | ad hoc | Anforderungen nach einem Kriterium sortieren | kleine Mengen, ein klares Kriterium |
| Top-Ten | ad hoc | die wichtigsten Anforderungen auswählen, ohne weitere Ordnung | erste Fokussierung |
| MoSCoW | ad hoc | Einordnung in Must, Should, Could, Won't | Releases mit festem Termin |
| Kano-Klassifikation | ad hoc bis analytisch | Einordnung in Basis-, Leistungs- und Begeisterungsfaktoren | Produktentwicklung mit Fokus auf Zufriedenheit |
| Paarweiser Vergleich | analytisch | jede Anforderung mit jeder anderen vergleichen | mittlere Mengen, strittige Prioritäten |
| Gewichtete Bewertung | analytisch | mehrere Kriterien mit Gewichten bewerten und summieren | nachvollziehbare Entscheidungen, viele Stakeholder |
Der Lehrplan unterscheidet Ad-hoc-Techniken und analytische Techniken [1]. Ad-hoc-Techniken sind schnell und eignen sich, wenn Erfahrung und gemeinsames Verständnis vorhanden sind. Analytische Techniken sind aufwendiger, machen die Entscheidung aber nachvollziehbar und überprüfbar. MoSCoW stammt aus dem DSDM-Rahmenwerk, das zudem empfiehlt, typischerweise höchstens 60 Prozent des Aufwands für Must Haves einzuplanen [2].
Rechenbeispiel: gewichtete Bewertung
Ein Team bewertet fünf Anforderungen an eine Zeiterfassungslösung nach vier Kriterien auf einer Skala von eins bis fünf. Die Gewichte werden vorab mit dem Auftraggeber vereinbart: Geschäftswert 0,4, Dringlichkeit 0,3, Risikoreduktion 0,2 und Einfachheit der Umsetzung 0,1. Einfachheit wird so bewertet, dass ein hoher Wert geringen Aufwand bedeutet. Die Summe der gewichteten Bewertungen ergibt die Priorität.
| Anforderung | Geschäftswert (0,4) | Dringlichkeit (0,3) | Risiko (0,2) | Einfachheit (0,1) | Summe |
|---|---|---|---|---|---|
| R1 Mobile Erfassung | 5 | 4 | 2 | 3 | 3,9 |
| R2 Export an Buchhaltung | 4 | 5 | 3 | 4 | 4,1 |
| R3 Ferienplanung | 3 | 2 | 1 | 2 | 2,2 |
| R4 Zwei-Faktor-Anmeldung | 3 | 4 | 5 | 4 | 3,8 |
| R5 Dashboards | 4 | 2 | 1 | 2 | 2,6 |
Die Reihenfolge lautet R2, R1, R4, R5, R3. Der Export an die Buchhaltung liegt knapp vor der mobilen Erfassung, weil er dringend ist und einen hohen Geschäftswert hat. Die Zwei-Faktor-Anmeldung liegt trotz mittlerem Geschäftswert weit vorne, weil sie ein hohes Risiko reduziert. Die Ferienplanung landet am Ende und ist ein Kandidat für «nicht im Umfang», zumal sie ohnehin im Personalsystem liegt. Wichtig ist die Plausibilitätsprüfung: Fühlt sich die Reihenfolge für Auftraggeber und Team richtig an? Wenn nicht, ist meist ein Gewicht oder eine Bewertung zu hinterfragen.
Priorisierung in agilen Vorhaben
In Scrum ist der Product Owner für die Ordnung des Product Backlogs verantwortlich; wer den Backlog ändern möchte, muss ihn überzeugen [3]. Die Priorisierung ist dort ein laufender Vorgang, der bei jedem Refinement und Sprint Planning überprüft wird. Methoden wie WSJF, MoSCoW oder RICE unterstützen diese Entscheidung. Ein Vergleich mit Rechenbeispielen findet sich im Beitrag Backlog priorisieren im Hub Agil.
Typische Fehler bei der Priorisierung
| Fehler | Folge | Gegenmittel |
|---|---|---|
| Alles ist Priorität eins | Priorisierung verliert ihren Sinn | Must-Anteil begrenzen, Rangfolge erzwingen |
| Kriterien nicht vereinbart | Diskussionen ohne Grundlage | Kriterien und Gewichte vorab festlegen |
| Nur ein Stakeholder bewertet | einseitige Prioritäten | relevante Stakeholder beteiligen |
| Unterschiedliche Abstraktionsebenen vermischt | unsinnige Vergleiche | auf gleicher Ebene priorisieren |
| Prioritäten nie überprüft | veraltete Reihenfolge | regelmässig neu bewerten, etwa pro Release |
Priorisierung im Werkzeug abbilden
Prioritäten gehören als Attribut zu jeder Anforderung, zusammen mit Bewertungen und Begründung. In Flenio lassen sich Anforderungen mit Priorität, Status und Meilenstein führen und nach diesen Kriterien filtern und sortieren. Wie Attribute und Sichten im Requirements Management eingesetzt werden, beschreibt der Beitrag Requirements Management. Den Gesamtzusammenhang zeigt der Leitfaden Requirements Engineering.
Wie funktioniert der paarweise Vergleich?
Beim paarweisen Vergleich wird jede Anforderung mit jeder anderen verglichen, jeweils mit der Frage: Welche der beiden ist wichtiger? Bei fünf Anforderungen sind das zehn Vergleiche, bei zehn Anforderungen bereits 45. Jede Anforderung erhält für jeden gewonnenen Vergleich einen Punkt; die Summe ergibt die Rangfolge. Der Vorteil liegt darin, dass Menschen zwei Optionen leichter gegeneinander abwägen können als viele gleichzeitig. Der Nachteil ist der wachsende Aufwand bei grossen Mengen, weshalb sich die Technik vor allem für die wichtigsten zehn bis fünfzehn Anforderungen eignet.
Wie hilft das Kano-Modell bei der Priorisierung?
Das Kano-Modell, das der IREB-Lehrplan für die Erhebung beschreibt, hilft auch bei der Priorisierung. Basisfaktoren müssen erfüllt sein, sonst entsteht Unzufriedenheit; sie gehören deshalb meist an den Anfang, auch wenn sie wenig Begeisterung auslösen. Leistungsfaktoren werden nach ihrem Beitrag zur Zufriedenheit gewichtet. Begeisterungsfaktoren können ein Produkt abheben, sind aber erst sinnvoll, wenn die Basis stimmt. Wer zuerst Begeisterungsfaktoren umsetzt und Basisfaktoren vernachlässigt, erhält ein Produkt mit beeindruckenden Funktionen, das im Alltag scheitert. Wie die Kategorien erhoben werden, beschreibt der Beitrag Anforderungen erheben.
Was tun, wenn Stakeholder sich nicht einigen?
Unterschiedliche Prioritäten verschiedener Stakeholder sind normal und Ausdruck unterschiedlicher Interessen. Der IREB-Lehrplan beschreibt dafür Konfliktlösungstechniken wie Einigung, Kompromiss, Abstimmung, Entscheid der Hierarchie und Varianten. Bei der Priorisierung hilft es zudem, die Kriterien und Gewichte vor der Bewertung gemeinsam festzulegen: Wer dem Gewicht für Risikoreduktion zugestimmt hat, akzeptiert eher, dass eine Sicherheitsanforderung vor seinem Wunsch steht. Bleibt der Konflikt bestehen, entscheidet die verantwortliche Stelle, etwa der Auftraggeber oder der Product Owner, und die Entscheidung wird mit Begründung dokumentiert.
Priorisierung ist zudem kein einmaliger Akt. Neue Informationen, veränderte Rahmenbedingungen oder erste Erfahrungen mit umgesetzten Anforderungen können Prioritäten verschieben. Eine regelmässige Überprüfung, etwa vor jedem Release oder jeder grösseren Planung, hält die Reihenfolge aktuell. Wie qualitativ hochwertige Anforderungen formuliert werden, die sich gut bewerten lassen, zeigt der Beitrag Anforderungen formulieren.
Wie wird die Priorisierung dokumentiert?
Prioritäten werden als Attribut jeder Anforderung geführt, ergänzt um die Bewertungen nach den einzelnen Kriterien, das Datum der Bewertung und die Beteiligten. Bei analytischen Techniken wird zudem die Bewertungstabelle aufbewahrt, damit spätere Fragen beantwortet werden können: Warum steht diese Anforderung hinten? Wer hat das entschieden? Auf welcher Grundlage? Diese Nachvollziehbarkeit ist besonders in öffentlichen Projekten und bei Verträgen mit externen Lieferanten wichtig, weil Prioritäten dort den Leistungsumfang einzelner Etappen bestimmen. Sie erleichtert zudem die regelmässige Überprüfung, weil sichtbar wird, welche Annahmen sich seither verändert haben.
Ein schlankes Vorgehen genügt dabei oft: Eine Tabelle mit Anforderung, Bewertungen, Summe, Entscheid und Datum, die im Projekt zentral abgelegt und bei jeder Überprüfung fortgeschrieben wird, schafft bereits die nötige Transparenz. Aufwendige Werkzeuge sind erst bei grossen Mengen von Anforderungen oder vielen beteiligten Teams nötig, etwa wenn mehrere Fachbereiche ihre Wünsche in denselben Umfang einbringen. Entscheidend ist nicht das Werkzeug, sondern dass Prioritäten sichtbar, begründet und aktuell sind.