Eigene Prioritätsbewertung in Jira: So passt du Dimensionsgewichte für dein Team an

Das Problem mit einer Bewertung für alle

RICE-Bewertung wurde bei Intercom für einen bestimmten Produktteamtyp entwickelt: nutzerbezogen, mit hoher Reichweite und vielen Daten. In diesem Kontext funktioniert die Formel hervorragend. Die meisten Teams sind aber nicht Intercom.

Ein B2B-Produktteam könnte 30 Kunden mit jeweils 50.000 Euro Jahresumsatz haben. Für sie sagt Reichweite (Nutzeranzahl) fast nichts aus. Eine Funktion mit großem Nutzen für alle 30 Kunden ist wertvoller als eine Funktion mit kaum spürbarem Nutzen für 5.000 Endnutzer. Standard-RICE würde trotzdem jedes Mal die Funktion mit hoher Reichweite zuerst einordnen.

Ein Plattformentwicklungsteam hat das entgegengesetzte Problem. Es arbeitet an Zuverlässigkeit, Leistung und Werkzeugen — mit fast keiner direkten Nutzerreichweite, aber enormer nachgelagerter Wirkung. Die Einfachheitsdimension von Standard-ICE bildet möglicherweise nicht ab, was „einfach“ beim Infrastruktur-Refactoring bedeutet.

Dimensionsgewichte lösen das. Du sagst dem Bewertungssystem: „Für unser Team ist Wirkung dreimal wichtiger als Reichweite.“ Die Formel bleibt gleich; die relative Bedeutung jedes Faktors ändert sich.

Was Dimensionsgewichte tatsächlich tun

Ein Gewichtsmultiplikator verstärkt den Einfluss einer Dimension auf den Gesamtwert. ×1 ist neutral — die Dimension fließt mit ihrem ursprünglichen Wert ein. ×3 verdreifacht ihren Beitrag gegenüber einer ×1-Dimension. ×5 macht sie zum dominierenden Faktor der Formel.

Die zugrunde liegende RICE-Formel bleibt unverändert — weiterhin (Reichweite × Wirkung × Sicherheit) ÷ Aufwand. Bevor die Werte multipliziert werden, wird aber jeder rohe Dimensionswert mit seinem Gewicht skaliert. Trägt Wirkung ×3 und Reichweite ×1, liegt eine Funktion mit hoher Wirkung deutlich vor einer Funktion mit gleicher Reichweite, aber geringerer Wirkung.

Das ist besonders beim Vergleich von Vorgängen wichtig. Die absolute Zahl verschiebt sich — die relative Rangfolge bestimmt aber dein Handeln.

Zwei Gewichtsprofile für zwei sehr unterschiedliche Teams

Profil 1 — B2B-Unternehmensteam

Ein Team verkauft Workflow-Software an Unternehmenskunden. Die Verträge sind groß, Nutzer sind Vielnutzer, und Kundenzufriedenheit entscheidet vor allem über Verlängerungen.

Mit diesem Profil erhält eine Funktion, die einen zentralen Unternehmensablauf tiefgreifend verändert, einen deutlich höheren Wert als eine kleine UX-Anpassung mit oberflächlichem Nutzen für viele Menschen — selbst wenn die UX-Anpassung absolut mehr Nutzer erreicht.

Profil 2 — Schnelles Growth-Team

Ein Start-up führt wöchentlich Produktexperimente durch. Das Team schätzt Tempo und Lernen. Sicherheit wird bewusst geringer gewichtet, weil es zum Lernen und nicht zur Gewissheit ausliefert. Einfachheit (entsprechend niedrigem Aufwand) wird belohnt.

Derselbe Vorgang unter beiden Profilen erzeugt stark unterschiedliche Rangfolgen — genau darum geht es. Bewertung soll deine Teamstrategie abbilden, kein allgemeines Verfahren für ein Unternehmen mit anderem Kontext.

Eigene Gewichte für WSJF und ICE

Dasselbe Gewichtssystem gilt für WSJF und ICE. Bei WSJF erhalten die drei Teilkomponenten der Verzögerungskosten — Geschäftswert, Zeitkritikalität und Risikoreduktion — jeweils ein Gewicht. Eine Organisation mit dominierenden regulatorischen Fristen im PI Planning könnte Zeitkritikalität mit ×4 gewichten. Ein Plattformteam mit Fokus auf technische Risiken könnte Risikoreduktion mit ×3 gewichten.

Bei ICE ändern Teams manchmal die Standardannahme zur Einfachheit. Standard-ICE gewichtet Wirkung, Sicherheit und Einfachheit gleich. Ein Team mit bewusst schwierigen technischen Problemen — und deshalb fast immer niedriger Einfachheit — könnte deren Gewicht reduzieren, damit schwierige, aber wirkungsvolle Arbeit nicht unfair benachteiligt wird.

Dimensionsgewichte in Jira konfigurieren

In Priority Scoring for Jira werden Gewichte je Projekt und Verfahren konfiguriert. Du kannst RICE im Produktbacklog mit einem Profil und im Infrastrukturprojekt mit einem anderen nutzen — innerhalb jedes Projekts bleiben die Werte vergleichbar.

1. 1
   Öffne die Priority-Scoring-Einstellungen. Öffne die globale Konfigurationsseite von Priority Scoring und wähle dein Projekt aus der Liste.
2. 2
   Wähle dein Verfahren. Wähle RICE, WSJF oder ICE über die Verfahrenstabs. Jedes hat eine unabhängige Gewichtskonfiguration.
3. 3
   Setze Gewichtsmultiplikatoren für jede Dimension. Passe über die Gewichtsauswahl (×1–×5) den Einfluss jeder Dimension an. Die Vorschau zeigt eine Beispielberechnung mit deinen aktuellen Gewichten.
4. 4
   Speichere die Konfiguration. Alle vorhandenen Werte deines Projekts werden automatisch neu berechnet. Öffne das Priority-Scoring-Dashboard, um die veränderte Rangfolge zu sehen.
5. 5
   Informiere dein Team über die Änderung. Nach einer Gewichtsänderung kann ein vorher führender Vorgang deutlich abrutschen. Informiere das Team, damit die Neuberechnung in der Sprint-Planung keine Verwirrung erzeugt.

Dimensionsgewichte in Priority Scoring for Jira — Multiplikatoren je Verfahren, sofortige Neuberechnung aller Werte

Der Wert mit Live-Vorschau in jedem Vorgang

Wenn ein Teammitglied Dimensionswerte in einem Jira-Vorgang setzt oder ändert, wird der Gesamtwert bereits vor dem Speichern unmittelbar berechnet. Dadurch wird das Gewichtssystem transparent. Die bewertende Person sieht: „Wenn ich Wirkung auf Hoch setze, steigt der Wert von 42 auf 85. Das liegt am Gewicht ×4 für Wirkung in unserem Verfahren.“

Die Live-Vorschau hat einen zweiten Vorteil: Sie erschwert überhöhte Bewertungen. Wer die unmittelbare Wirkung jeder Reglerposition sieht, schätzt bewusster. Alles mit „Hoher Wirkung“ zu versehen wird offensichtlich wenig hilfreich, wenn der Live-Wert bei Vorgängen mit geringer Wirkung fast null beträgt.

Eigene Gewichtsprofile werden in der Live-Bewertungsanzeige jedes Jira-Vorgangs berücksichtigt

Gewichtsänderungen im Zeitverlauf verfolgen

Dimensionsgewichte nach mehreren Monaten Bewertung zu ändern, ist ein wichtiges Ereignis. Die gesamte Backlog-Rangfolge verschiebt sich. Priority Scoring for Jira protokolliert Gewichtsänderungen im „Score Audit Trail“ neben einzelnen Bewertungsänderungen. Du siehst Zeitpunkt, Werte vorher und nachher und die am stärksten betroffenen Vorgänge.

Das hilft besonders in Retrospektiven. Wenn das Team vermutet, dass das aktuelle Profil keine hilfreichen Rangfolgen erzeugt — etwa weil hoch bewertete Einträge regelmäßig in der Planung zurückgestellt werden —, zeigt das Protokoll die letzte Gewichtsprüfung und tatsächliche Veränderungen im Bewertungsverhalten.

Einen umfassenderen Blick auf den Beitrag deiner Bewertungen zur Backlog-Qualität gibt die Kennzahl zur Jira-Backlog-Gesundheit — sie kombiniert Bewertungsabdeckung, veraltete Vorgänge und fehlende Felder zu einem einzigen Projektqualitätswert von 0–100.

Wann du dein Gewichtsprofil überprüfen solltest

Gewichtsprofile sind keine einmalige Einstellung. Diese Signale deuten auf unpassende Gewichte hin:

• Hoch bewertete Vorgänge werden in der Sprint-Planung regelmäßig zurückgestellt. Wenn das Team die Rangfolge immer wieder übergeht, bilden die Gewichte möglicherweise seine tatsächlichen Entscheidungen nicht ab.
• Werte liegen zu dicht beieinander. Wenn 80 % deines Backlogs in einem engen Wertebereich liegen, erhöhe das Gewicht der Dimension mit der größten tatsächlichen Streuung.
• Die Teamstrategie hat sich verändert. Beim Wechsel von Wachstum zu Zuverlässigkeit sollte Reichweite wahrscheinlich weniger zählen als Sicherheit. Passe das Profil an die neue Richtung an.
• Neue Teammitglieder einarbeiten. Eine gemeinsame Gewichtungsabstimmung bei der Einarbeitung hilft neuen Produktmanagern, Teamprioritäten ausdrücklich zu verstehen, statt sie nur indirekt aus dem Backlog zu erschließen.

Häufig gestellte Fragen