WSJF Agile Framework

Weighted Shortest Job First (WSJF) hilft dir, Arbeit zu priorisieren, indem es Verzögerungskosten gegen Jobgröße ausbalanciert. Dieses Framework liefert maximalen Wert mit begrenzten Ressourcen in sich schnell verändernden Umgebungen.

WSJF-Priorisierung in Kürze

Erstelle ein kostenloses Ducalis-Konto

WSJF-Berechnung

WSJF-Score = (Geschäftswert + Zeitkritikalität + Risikominderung) / Jobgröße

Kriterien

Nutzer-/Geschäftswert bewertet Jobs nach ihrer Bedeutung für Nutzer und potenziellem Umsatzeinfluss.

Zeitkritikalität bewertet Jobs nach Dringlichkeit – wie schnell der Wert verfällt oder wie viele Kunden du durch Verzögerung verlieren könntest.

Risikominderung und Opportunity Enablement hebt Jobs hervor, die möglicherweise nicht sofort Umsatz bringen, aber langfristige Ergebnisse verbessern. Einige Lösungen eliminieren technische oder rechtliche Risiken und sparen später Geld.

Job Duration (auch Story Points, Feature Points, Aufwand oder relative Größe genannt) misst die Implementierungskomplexität. Bei dieser Schätzung sind kleinere Zahlen besser.

Bewertung

1. Bewerte jedes Kriterium auf der Fibonacci-Skala: 1 (keine Auswirkung), 2, 3, 5, 8, 13, 21 (höchste Auswirkung).

2. Führe kollaborative Priorisierungssitzungen mit Teams von fünf bis elf Personen durch.

3. Bewerte Aufgaben vor jedem Iterationsplanungsevent (Sprint).

4. Normalisiere unterschiedliche Scores durch Diskussionen mit Teammitgliedern.

5. Teile Initiativen mit '21' und '13' Job Sizes in kleinere Projekte auf (Backlog Refinement).

6. Setze Bewertungsscores alle fünf Iterationen (Program Increment) zurück, um die sich schnell verändernde Umgebung widerzuspiegeln.

Wende das sofort einsatzbereite Ducalis-Priorisierungs-Template an

Du musst Kriterien, Formeln und Skalen nicht anpassen. Verwende sie als Vorlage, um das Meeting zu starten.

Hinweis

WSJF ist nicht nur eine Formel – es ist Teil eines umfassenden Workflow-Frameworks für Unternehmen. Die Magie geschieht, wenn du deinen Entscheidungsansatz änderst: Führe kollaborative Priorisierungssitzungen durch, setze Score-Ablaufdaten fest, spezifiziere Kriterien und erkläre Aufgabenbeschreibungen deinen Teammitgliedern. Dieser Artikel bietet Tools, um diese Priorisierungsgewohnheit zu schaffen und deine Denkweise zu verändern.

WSJF-Definition

WSJF steht für Weighted Shortest Job First – ein Priorisierungs-Framework zur Priorisierung von Backlogs durch Berechnung der relativen Cost of Delay (CoD) und Jobgröße (ein Näherungswert für die Dauer). CoD berechnet sich als Summe: Nutzer-/Geschäftswert + Risikominderung und Opportunity Enablement + Zeitkritikalität. Es ist Teil der SAFe-Methodik.

Backlog-Prioritäten werden kontinuierlich basierend auf WSJF-Prioritätswerten aktualisiert. Das Framework ignoriert praktischerweise und automatisch versunkene Kosten, ein grundlegendes Prinzip der Lean-Ökonomie.

In einem flussbasierten System liefert kontinuierliche Aufgabenpriorisierung zur Aktualisierung von Prioritäten die besten wirtschaftlichen Ergebnisse für:

• Job-Sequenzierung durch Vorantreiben schneller Erfolge
• Balance des höchsten finanziellen Ergebnisses bei gleichzeitiger Senkung investierter Ressourcen
• Regelmäßige Aktualisierung von CoD und Job Sizes, um die sich schnell verändernde Umgebung widerzuspiegeln

Was ist SAFe?

Das Scaled Agile Framework (SAFe) ist laut ScaledAgile.com ein System zur Implementierung von Agile-, Lean- und DevOps-Praktiken in großem Maßstab. Es nimmt die besten Ideen aus agiler Produktlieferung und erweitert sie auf das gesamte Unternehmen, um Business Agility zu bieten. SAFe ist das beliebteste Framework für führende Unternehmen, weil es funktioniert: Es ist bewährt, anpassbar und nachhaltig.

Es wird ständig aktualisiert und hat Versionen. 2022 ist die neueste Version 5.1, und SAFe deckt sieben Hauptbereiche des Unternehmens ab:

• Team and Technical Agility
• Agile Product Delivery
• Enterprise Solution Delivery
• Lean Portfolio Management
• Organization Agility
• Continuous Learning Culture
• Lean-Agile Leadership

Versprochene Ergebnisse:

• +50% schnellere Time-to-Market
• +50% Fehlerreduzierung
• +35% Produktivitätssteigerung
• +30% glücklichere, engagiertere Mitarbeiter

In diesem Artikel konzentrieren wir uns auf das Fundament – das WSJF-Entscheidungs-Framework.

Lade kostenlos das WSJF-Template herunter:

Wie man WSJF berechnet

WSJF-Formel

Das Weighted Shortest Job First (WSJF) Framework hilft dir zu entscheiden, welche Aufgabe als Nächstes zu wählen ist, um den größten Wert mit begrenzten Ressourcen zu liefern, indem es ein Gleichgewicht zwischen Cost of Delay (CoD) und Job Size in einer sich schnell verändernden Welt findet.

WSJF-Score berechnen

WSJF-Score = Cost of Delay / Job Size

Berechne CoD, die drei Arten von Produktentwicklungsproblemen definiert, die du beobachten solltest.

Cost of Delay = Nutzer-Geschäftswert + Zeitkritikalität + Risikominderung | Opportunity Enablement Value

Bewerte jedes Kriterium mit einer Skala von 1, 2, 3, 5, 8, 13, 21.

Schätzungsprinzipien:

• WSJF-Schätzung zielt darauf ab, das Ausmaß der Unsicherheit zu verstehen, nicht Stunden oder Geld zu berechnen (was nahezu unmöglich ist). Deshalb schätzen wir Wahrscheinlichkeit statt exakter Zeit für die Erledigung einer bestimmten Aufgabe. Das nennt man relative Bewertung.

• Da das Hauptziel darin besteht, in jeder Iteration Wert zu liefern, ist der Median der Sequenz „eine Iteration".

• Eine Iteration = zwei Wochen. Unser Planungs-Baseline. Wir berechnen Story-Point-Zahlen für eine zweiwöchige Iteration.

• Program Increment (PI) = fünf Iterationen (zehn Wochen). Laut SAFe ist ein PI eine Timebox, während der ein Agile Release Train (ART) inkrementellen Wert in Form von funktionierender, getesteter Software und Systemen liefert. Das gesamte Team realisiert etwas Großes für das Produkt. Mit anderen Worten, die Organisation veröffentlicht ein großes Update, nach dem sie ihr Backlog neu bewerten, nachdenken und Prioritäten erneut diskutieren sollte.

Anpassung

Dies ist nur eine Empfehlung, und du kannst den Ansatz auf jede Weise anpassen, die für dein Team angenehm ist. Später in diesem Artikel behandeln wir, wie du die Kriterien genau für deine geschäftlichen Anforderungen besser verstehen und anpassen kannst.

Nutzer-Geschäftswert (UBV)

Neue Features und Innovationen, die dein Produkt voranbringen. Zum Beispiel helfen Enterprise-Security-Login-Optionen, Beschwerden von Großkunden zu vermeiden, was zu Verkäufen führt.

Nutzer-/Geschäftswert (UBV) bewertet deine Jobs nach ihrer relativen Bedeutung für den Nutzer (Priorisierung der Erwünschtheit) und potenziellen Auswirkungen auf den Umsatz (Finanzielle Priorisierung). An diesem Punkt schätzt du ein, wie effektiv diese Lösung deine North Star Metric fördert. Da viele Faktoren UBV beeinflussen können, beginne mit der Überlegung zur geschäftlichen Auswirkung und erhöhe dein Vertrauen, dass alles funktionieren wird.

Zu beantwortende Fragen: Welche wichtige Produktkennzahl kannst du aktualisieren? Wie wichtig ist dies für Nutzer? Was ist die Auswirkung auf den Umsatz?

Nutzer-Geschäftswert-Bewertung mit Fibonacci-Sequenz

• 1 Punkt: überhaupt kein Nutzer-Geschäftswert; diese Aufgabe bezieht sich auf etwas anderes
• 2 Punkte: die geringste geschäftliche Auswirkung und Sicherheit
• 3 Punkte: geringe geschäftliche Auswirkung und Sicherheit
• 5 Punkte: moderate geschäftliche Auswirkung, moderate Sicherheit
• 8 Punkte: hohe geschäftliche Auswirkung und Sicherheit
• 13 Punkte: sehr hohe geschäftliche Auswirkung und Sicherheit
• 21 Punkte: die höchste geschäftliche Auswirkung und Sicherheit

Zeitkritikalität (TC)

Bewerte Dringlichkeit. Initiativen haben begründete Fristen wie neue Vorschriften, Steuerberichterstattung, saisonale Promotionen usw.

Zeitkritikalität bewertet Jobs nach Dringlichkeit. Du schätzt ein, wie schnell der Wert im Laufe der Zeit verfällt oder wie viele Kunden du verlieren könntest, wenn du zögerst.

Unser Schätzungszeitrahmen reicht von einer Iteration (zwei Wochen) bis zu einem Program Increment (PI) (zehn Wochen). Jeden PI-Zyklus führen wir eine neue Neubewertungssitzung durch (nach Score-Ablauf) und entscheiden, wie sich die Dringlichkeit verändert hat.

Zu beantwortende Fragen: Wie dringend ist es für das Geschäft? Werden Nutzer warten oder zu einer anderen Lösung wechseln? Gibt es eine feste Frist?

Zeitkritikalitäts-Bewertung mit Fibonacci-Sequenz

• 1 Punkt: überhaupt keine zeitkritische Aufgabe
• 2 Punkte: kann bis zum nächsten Schätzungszyklus warten (nach Score-Ablauf alle fünf Iterationen)
• 3 Punkte: kann vier Sprints warten (etwa acht Wochen)
• 5 Punkte: moderate Dringlichkeit, kann drei Sprints warten (etwa sechs Wochen)
• 8 Punkte: kann zwei Sprints warten (etwa vier Wochen)
• 13 Punkte: kann einen Sprint warten (etwa zwei Wochen)
• 21 Punkte: höchste Dringlichkeit, du musst dieses Issue zum nächsten Sprint nehmen

Risikominderung | Opportunity Enablement Value (RR | OE)

Aufgaben zur Vermeidung oder Reduzierung technologischer oder geschäftlicher Risiken. Beispiele sind Code-Refactoring, Datenbank-Update, Sicherheit oder Steuerprüfung – etwas, das du tun musst, um den gesunden Betrieb eines Produkts sicherzustellen.

Risikominderung und Opportunity Enablement helfen dir, Jobs hervorzuheben, die möglicherweise nicht sofort Umsatz bringen, aber langfristig Vorteile bringen. Einige Lösungen eliminieren technische oder rechtliche Risiken und sparen dir später Geld. Andere können Türen für weitere Verbesserungen öffnen, die die Anzahl potenzieller Kunden erheblich erhöhen.

Zu beantwortende Fragen: Wenn die Aufgabe mit einer Risikobeschreibung beginnt, wie groß ist die Auswirkung dieses Risikos? Welche Wahrscheinlichkeit?

Risikominderungs-Bewertung mit Fibonacci-Sequenz

• 1 Punkt: bietet überhaupt keine Risikominderung
• 2 Punkte: reduziert die Wahrscheinlichkeit eines geringsten Risikos, geringste Schweregrad-Wahrscheinlichkeit
• 3 Punkte: reduziert die Wahrscheinlichkeit eines geringen Risikos, geringe Schweregrad-Wahrscheinlichkeit
• 5 Punkte: reduziert die Wahrscheinlichkeit eines moderaten Risikos, moderate Schweregrad-Wahrscheinlichkeit
• 8 Punkte: reduziert die Wahrscheinlichkeit eines moderat-hohen Risikos, hohe Schweregrad-Wahrscheinlichkeit
• 13 Punkte: reduziert die Wahrscheinlichkeit eines sehr hohen Risikos, sehr hohe Schweregrad-Wahrscheinlichkeit
• 21 Punkte: kann das Risiko eines höchst einflussreichen Ereignisses reduzieren, eine Katastrophe, die sehr wahrscheinlich eintritt

Jobgröße (Job Duration)

Jobgröße ist der einzige negative Faktor und bewertet Jobs nach der Realisierungskomplexität. Es ist unmöglich, den höchsten ROI zu erreichen, ohne die Kosten der erforderlichen Personenstunden zu berücksichtigen. Duration wird auch Story Points, Feature Points, Aufwand oder relative Größe genannt.

Zu beantwortende Fragen: Wie lange wird die Implementierung dauern? Gibt es Abhängigkeiten, die sie zeitaufwändiger machen können?

Jobgrößen-Bewertung mit Fibonacci-Sequenz (Story Points)

• 1 Punkt: überhaupt kein Aufwand erforderlich. Wir können nicht durch Null teilen, daher sollte unsere Jobgrößen-Schätzung bei 1 beginnen.
• 2 Punkte: die Schätzungs-Baseline. 80% Wahrscheinlichkeit, dass ein Tag zum Codieren ausreicht und ein Tag zum Testen und Validieren für eine zweiwöchige Iteration.
• 3 Punkte: eine Aufgabe etwa ein Viertel deiner Sprint-Bemühungen
• 5 Punkte: etwas die Hälfte deiner Iteration. 80% Wahrscheinlichkeit, dass die Aufgabe 5 Arbeitstage zum Codieren benötigt und einen Tag zum Testen und Validieren für eine zweiwöchige Iteration.
• 8 Punkte: 80% Wahrscheinlichkeit, dass eine Aufgabe innerhalb von zwei Wochen entwickelt und getestet wird (eine Iteration/Sprint)
• 13 Punkte: zwischen einer und zwei Iterationen
• 21 Punkte: „Buzz Lightyear-Schätzungen", etwas, das zwei Sprints oder noch mehr dauert („bis zur Unendlichkeit und darüber hinaus"). Aus meiner praktischen Erfahrung bei der Arbeit mit Teams wirst du viele Ideen bewerten, die eine Iteration überschreiten und in kleinere Stücke geteilt werden sollten.

Die endgültige Formel zur Berechnung des WSJF-Scores:

WSJF-Score = (Geschäftswert + Zeitkritikalität + Risikominderung | Opportunity Enablement) / Jobgröße

Kriterien für dein Team anpassen

Im Standard-Scrum-Framework ist die Story-Point-Schätzung jedes Teams – und die daraus resultierende Velocity – ein lokales und unabhängiges Anliegen. Hier ist ein Ausgangspunkt für deinen Bewertungsprozess. Du kannst ihn aus dem Ducalis WSJF-Template anwenden und die Kriterienbeschreibungen ändern.

Es gibt keine einzige richtige Definition für eine Skala. Wenn du und dein Team durch irgendeinen Begriff verwirrt seid – ändere ihn! Ducalis ist in dieser Hinsicht ziemlich flexibel.

Iterationen

Der Kern agiler Prozesse sind die grundlegenden Bausteine, die Iterationen oder Sprints genannt werden. Jede Iteration ist eine standardmäßige Timebox mit fester Länge, in der Agile Teams inkrementellen Wert liefern.

Iterationsplanungsevent (Product Increment)

Jede Iteration sollte mit einer klaren Prioritätenliste beginnen. Vor dieser Planung solltest du ein bewertetes Backlog haben. Teams verbringen oft die ganze Woche zwischen Entwicklungszyklen für Bewertung, Priorisierung und Planung. Dann liefern sie Wert in kurzen Iterationen (Sprints).

Ducalis kann diese ganze Woche für dein Team durch einen asynchronen Bewertungsprozess sparen. Lege einen Planungstag fest, und Ducalis erledigt den Rest. Du kannst den Bewertungsfortschritt mit dem Team-Bewertungsfortschrittsbericht verfolgen.

Um deine Teammitglieder zu motivieren, rechtzeitig zu bewerten, biete Unterstützung mit ermutigenden Nachrichten. Gehe zu den Priorisierungsgewohnheits-Einstellungen und setze eine belohnende Nachricht für Teammitglieder, die ihre Bewertung rechtzeitig vor dem bevorstehenden Iterationsplanungsmeeting abschließen.

Die Kraft der Neubewertung

Top-Prioritäten, Dringlichkeit und geschäftliche Werte sind verderbliche Produkte. Es gibt so viel Input – neue Kundenanfragen, Bugs, technische Schulden, neue Vorschriften, ausgefallene Ideen und vieles mehr.

Die ganze Idee von SAFe besteht darin, sich auf neue Weise an eine sich schnell verändernde Welt anzupassen. Die Umgebung eines Unternehmens ändert sich alle fünf Iterationen (ein PI). Daher wird dringend empfohlen, Bewertungsscores zurückzusetzen.

In einem flussbasierten System liefert kontinuierliche Aktualisierung von Prioritäten die besten wirtschaftlichen Ergebnisse. Job-Sequenzierung statt theoretischer, individueller Job-Return on Investment erzeugt das beste Ergebnis in einem solchen Flusskontext.

Ein Nebeneffekt der Backlog-Neubewertung ist Backlog Grooming/Refinement. Während du über jedes Backlog-Item nachdenkst, wirst du einige Ideen bekommen, wie du deine Aufgabe zusammenführen, aktualisieren oder entfernen kannst, da einige Informationen aus irgendeinem Grund veraltet sein werden. Aus der Erfahrung von hi.ducalis.io entfernen wir 2% bis 5% unserer Backlog-Items bei jedem Neubewertungszyklus.

Um Neubewertungszyklen einzurichten:

1. Klicke auf Meeting in # days (Meeting in # Tagen).
2. Scrolle nach unten zum Abschnitt Score-Ablauf.

Standardmäßig laufen die Bewertungsscores deines Teams nach Beginn des nächsten PI-Zyklus ab.

Standardmäßig ist der Sprint zwei Wochen lang. Passe ihn im Abschnitt Priorisierungsgewohnheiten an.

Pro-Tipp

Wenn deine Scores abgelaufen sind und du das vorherige PI nicht abgeschlossen hast, kannst du deine Scores immer wiederherstellen und den Priorisierungszeitraum verlängern.

Kollaborative Priorisierung

Agile-Schätzung ist ein Teamsport. Jedes agile Team besteht aus fünf bis elf Mitgliedern. Lade dein agiles (cross-funktionales Team) zum Priorisierungsprozess ein.

Wenn ein Team das Product Backlog schätzt, wissen sie nicht, wer an jeder Aufgabe arbeiten wird. Teams bestimmen das normalerweise während der Iterationsplanung (Sprint).

Deshalb bewertet das gesamte agile Team jedes Product Backlog-Item.

Verzerrung reduzieren

Das gesamte Team muss die Logik hinter der Zuweisung der Story Points verstehen, um eine konsistente Praxis zu erreichen. Alle Teammitglieder stimmen ab, ohne von anderen Teammitgliedern beeinflusst zu werden. Äußerer Druck oder unzureichendes Teaming kann Story Points schnell aufblähen und die Prognose beeinträchtigen.

Manchmal können Priorisierungsmeetings von der lautesten Person im Raum geleitet werden. Das bedeutet, ihr könnt euch während der Bewertungssitzung gegenseitig stören. Lass jeden in seinem eigenen Tempo priorisieren.

Wähle 'The Right Impact'

Wir haben am Anfang des Artikels über die geschäftliche Auswirkung gesprochen. Aber welche Antworten wirst du bekommen, wenn du verschiedene Rollen fragst: eine einfache Frage „Was ist das Wirkungsvollste, was wir als Nächstes tun sollten?" Zum Beispiel wette ich, ein Entwickler wird dir „schnellere Datenbank" sagen, ein Verkäufer wird „eine Feature-Anfrage für den größten Kunden" sagen, und ein Product Manager wird „neue Retention-Nachricht" fragen, usw.

Es ist nahezu unmöglich zu vergleichen, was wirkungsvoller ist. Das ist jedoch eine gute Sache, die jedes agile Team berücksichtigen sollte, und genau das kann Ducalis für dich handhaben.

Sammle verschiedene Meinungen

Priorisierungs-Frameworks sind großartig, um Emotion und Politik aus einer Entscheidung herauszuhalten, damit du dich stattdessen auf Fakten verlassen kannst. Wenn du jedoch allein priorisierst, bist du immer noch voreingenommen. Übernimm die Poker-Planning-Technik für die Priorisierung. Lade mit Ducalis jedes Teammitglied zur Priorisierung ein.

Um Teammitglieder einzuladen:

1. Öffne die Kriterien-Einstellungen.
2. Lade Teammitglieder zu deinem gemeinsamen Bewertungsteam ein.

Dies gibt jedem Teammitglied seine eigene Bewertungsliste für unabhängige Schätzung.

Kriterien für jede Rolle spezifizieren

Nehmen wir an, du musst ein neues Feature für deine Website entwickeln. Du hast mindestens drei Rollen – UX-Designer, Front-End und Back-End – alle haben eine unterschiedliche Jobgröße für dieses Feature. UX benötigt eine Jobgröße von 3 Tagen, das Front-End benötigt einen Tag und das Back-End benötigt fünf Tage. Was ist die Jobgröße für das Gesamtprojekt?

Das Problem ist nicht die Berechnung; dein Team sollte einen Zeitrahmen finden, um darüber zu diskutieren. In einer Remote-First-Welt bedeutet das einen weiteren Zoom-Anruf und Diskussion. Mehr Arbeit um Arbeit.

Ducalis kann das für dich mit einem asynchronen Priorisierungsansatz handhaben.

Um Kriterien nach Rolle zuzuweisen:

1. Öffne die Kriterien-Einstellungen.

2. Weise jedem Nutzer ein Kriterium zu, das er gemäß seiner Expertise schätzen soll.

   

Danach wird jedes Teammitglied Backlog-Items mit seinem Kriteriensatz bewerten, für den es verantwortlich ist zu schätzen.

Wenn alle teilnehmen, erhöht es die Zustimmung

Der Nebeneffekt kollaborativer Priorisierung ist, dass Teammitglieder besser verstehen, was mit dem Produkt los ist. Wir wissen, welche Herausforderungen, Anfragen und Ideen wir haben und warum einige wichtiger sind als andere. Es erhöht Moral und Teambeteiligung.

Scores normalisieren

Ein bisschen Normalisierung erfolgt durch regelmäßige Praxis und hilft sicherzustellen, dass jeder im Team die gleichen Annahmen hinter der Größenbestimmung macht. Wenn zum Beispiel eine Person ein Item mit „2" bewertet, aber eine andere Person es mit „8" bewertet, und sie ähnliche Fähigkeiten teilen, haben sie die Anforderung unterschiedlich interpretiert oder sind von verschiedenen Richtungen an sie herangegangen. Wenn dies geschieht, arbeiten die Entwickler mit dem Product Owner zusammen, um Annahmen zu klären und sich auf eine Größe zu einigen. (Dies muss kein Konsens sein – Menschen können zustimmen, nicht zuzustimmen.)

Während ein Team lernt, was die Fibonacci-Skala für sie bedeutet, mit ihren einzigartigen Fähigkeiten, ihrer Betriebszugehörigkeit und ihrem Domänenwissen, ist es hilfreich, neue Anfragen mit abgeschlossener Arbeit mit gemeinsamen Ähnlichkeiten zu vergleichen. Wenn zum Beispiel einem neuen Item ein Story-Point-Wert von 5 zugewiesen wird, vergleiche es mit ähnlichen Dingen mit derselben Größe und passe die Punkte entsprechend an.

Mit Ducalis kannst du schnell den Team-Übereinstimmungsbericht überprüfen, um eine Heatmap der Meinungsverschiedenheiten zu erhalten. Dies ist ein weiteres Tool für asynchrone Priorisierung anstatt einer Poker-Planning-Sitzung, bei der die Mehrheit der Schätzungen überhaupt keine Diskussion benötigt.

In kleinere Stücke teilen

Eines der größten Missverständnisse über WSJF ist, dass es dein Team nur auf einfache Aufgaben fokussieren könnte (niedrig hängende Früchte). Stattdessen gilt: Je kleiner die Jobgröße für eine bestimmte Aufgabe, desto höher der Prioritätswert und desto höher wird die Aufgabe eingestuft.

Verwende eine Matrix zum Aufteilen deines Backlogs in Teile und entscheide, was du mit deinen Aufgaben tun sollst.

Durch die Praxis des Refinement – Arbeit in kleinere, wertvollere Stücke zu unterteilen – gewinnen die Entwickler weiterhin Erkenntnisse. Da jede Anfrage kleiner wird und mehr bekannt ist, überdenken sie kontinuierlich die Größe. Daher ist es gut, drei Berührungspunkte bereitzustellen, um dem Team mit dem entstehenden Design, der Entwicklung und den Abhängigkeiten zu helfen.

Praktische Ratschläge

• Versuche nicht, zu präzise zu sein. Wenn du eine Aufgabe für eine Stunde hast, scheue dich nicht, eine Baseline für einen Tag festzulegen. Es wird sich alles auf lange Sicht kompensieren und ausgleichen.

• Runde Schätzungen auf den nächsten Wert auf.

• Die endgültige Entscheidung bleibt jedoch beim Produktverantwortlichen, der für die Sequenzierung der Items im fraglichen Backlog verantwortlich ist. Faktoren wie regulatorische Fristen, Fragilität von Legacy-Systemen oder der Aufbau einer Grundlage für zukünftige Features können schwer in finanzielle Begriffe zu fassen sein, müssen aber dennoch berücksichtigt werden.

Verwandte Ressourcen

• WSJF Google Sheets-Template

---

hi.ducalis.io ist nicht mit Scaled Agile Framework oder SAFe verbunden. Lies ihre Vision und ihr Manifest unter https://www.scaledagileframework.com/