Was vorher fertig sein muss
Pro zu schätzendem Item liegen Akzeptanzkriterien vor, sodass Aufwand auf einen klar abgegrenzten Scope bezogen ist.
Was vor Start vorliegen muss
Schätz-Sheet mit Spalten Item, Ideal Days, Annahmen, Abhängigkeiten; Definition „Ideal Day“ sichtbar an der Wand; Liste der Referenz-Items mit Ideal-Day-Werten; Timer.
Ein Facilitator, der Definition wachhält und Werte sammelt; das umsetzende Team (2-9 Personen); ein Scribe für Annahmen und Caveats; optional ein PO für Scope-Klärung.
Item-Liste mit Akzeptanzkriterien; Definition „Ideal Day“ (z. B. „8 h fokussierte Arbeit ohne Meetings, Wartezeit, Kontextwechsel“); zwei bis drei Referenz-Items aus realer Liefer-Historie mit Ideal-Day-Wert.
15-60 min
Definition „Ideal Day“ als Banner an die Wand: „Tag konzentrierter Arbeit, keine Unterbrechung, keine Meetings, keine Blocker.“ Referenz-Items mit Werten sichtbar. Hinweis: Ideal Day ≠ Kalendertag.
Die eine Frage, die diese Methode beantwortet
Wie viele ideale Arbeitstage braucht dieses Item unter konzentrierter Arbeit, und welche Annahmen über Unterbrechung, Abhängigkeit und Unsicherheit werden dabei getroffen?
Marker: Phase
| Schritt | Dauer | Aktion | Hinweis |
|---|---|---|---|
1Phase 1: Definition und Referenzen schärfen | 10 min | Definition „Ideal Day“ gemeinsam durchgehen. Referenz-Items mit Werten ansehen, ggf. anpassen. Team-Konsens festhalten. | Wenn jemand glaubt „mein Ideal Day ist 6 h, ich habe Kinder“, ist die Definition zu lebensnah formuliert. Ideal Day ist methodische Einheit, kein realer Arbeitstag. |
2Phase 2: Items schätzen | 20-30 min | Pro Item Team-Schätzung in idealen Tagen. Diskussion bei Abweichung, ähnlich Planning Poker. Annahmen dokumentieren (z. B. „nutzt bestehende Library X“). | Wenn Item größer als 5 Ideal Days, splitten oder als Spike vorschalten. Größere Werte sind nicht belastbar, weil Annahmen-Vielfalt zu groß wird. |
3Phase 3: Abhängigkeiten und Caveats festhalten | 10-15 min | Pro Item explizit: welche Abhängigkeiten könnten Kalenderzeit aufblähen. Caveats notieren (z. B. „braucht Review von externem Team“, „Compliance-Freigabe erforderlich“). | Ideal Days ohne Caveats werden in Kalendertage umgedeutet. Caveats sind methodischer Schutz vor Fehlinterpretation. |
4Phase 4: Kalenderzeit-Faktor anwenden | 5-10 min | Für Planungssicht Ideal Days mit empirischem Faktor (typisch 1,5-3x) in Kalenderzeit übersetzen. Faktor aus Team-Historie ableiten. Bandbreite kommunizieren, nicht Punktwert. | Wenn kein historischer Faktor existiert, mit 2x als konservativem Default starten und nach 2-3 Sprints kalibrieren. Faktor ist Team-spezifisch und ändert sich mit Org-Kontext. |
Was am Ende rauskommt
Schätz-Tabelle mit Spalten Item, Ideal Days, Annahmen, Abhängigkeiten, Caveats, abgeleitete Kalenderzeit-Range. Definition „Ideal Day“ als Header. Verlinkt mit Backlog und Liefer-Historie.
Ideal-Day-Werte im Item gepflegt. Bei Re-Estimation alte Werte als Kommentar erhalten. Kalenderzeit-Faktor zentral gepflegt, mit Historien-Beleg (z. B. letzte 5 Items mit Ideal-Days-Schätzung und realer Lieferzeit).
Kompakte Arbeitsvorlage für Ideal Days mit Kontext, Input, Ergebnisartefakten und nächstem Schritt.
# Ideal Days Arbeitsvorlage
## Ziel
Schätzt Arbeit in idealisierten Arbeitstagen ohne Unterbrechungen, Meetings oder Wartezeiten.
## Kontext
Wann und wofür nutzen wir diese Methode?
## Input
Welche Daten, Beobachtungen, Entscheidungen oder Materialien liegen vor?
## Durchführung
Kurze Notizen entlang des Run Sheets.
## Ergebnisartefakte
- Ideal Day Estimates:
- Assumption Notes:
- Capacity Caveats:
## Annahmen und offene Fragen
- ...
## Entscheidung / Nächster Schritt
Owner, Datum und Erfolgssignal.Konkret gefülltes Szenario
## Ideal Days - Sprint 23 Refinement, 2026-05-18
**Definition Ideal Day**: 8 h konzentrierte Arbeit ohne Meetings, Wartezeit, Kontextwechsel. Kalenderzeit-Faktor Team: 2,5x (Historie der letzten 5 Items).
| Item | Ideal Days | Annahmen | Kalenderzeit |
|------|-----------|----------|--------------|
| API-Endpoint Mandanten-Export | 2 | nutzt Pagination-Helper, JSON+CSV | 5 Tage |
| DATEV-Import-Validierung | 3 | Library passt, Beispieldaten verfügbar | 7-8 Tage |
| Empfehlungsprompt im Dashboard | 1 | UI-Komponente existiert, nur Logik neu | 2-3 Tage |
| Webhook-System Basis | 4 | neue Infrastruktur, Compliance-Review nötig | 10-12 Tage |
**Caveats**
- Webhook-System: Compliance-Review kann +3 Kalendertage kosten (externe Abhängigkeit).
- DATEV-Import: bei Library-Versagen +5 Ideal Days (markiert als Risiko).
**Faktor-Kalibrierung**: Letzte 5 Items hatten Ratio Real/Ideal zwischen 2,1 und 2,8. Mittelwert 2,5 für aktuelle Planung. Nach Sprint 23 neu prüfen.Symptome erkennen, gegensteuern
Stakeholder oder PM liest „3 Ideal Days“ als drei Werktage Lieferzeit.
Konsequent mit Kalenderzeit-Faktor kommunizieren: „3 Ideal Days = 7-8 Kalendertage“. Banner mit Definition in jedes Schätzdokument. Wer nur Ideal Days nennt, lädt Fehlinterpretation ein.
Team nutzt seit 2 Jahren denselben Faktor 2x, Realität liegt inzwischen bei 3,5x.
Pro Sprint oder Quartal Faktor aus letzten 5-10 Items neu berechnen. Bei Faktor über 3x prüfen, ob ideale Bedingungen unrealistisch sind oder Organisation Engpässe hat.
Diskussion „mein Ideal Day ist 6 h“ verschiebt die Skala, Schätzwerte werden inkompatibel.
Definition als methodische Konstante behandeln (typisch 8 h konzentrierte Arbeit). Nicht an persönliche Realität anpassen, sonst wird Vergleich unmöglich.
Tabelle hat Ideal-Days-Werte, aber keine Annahmen, Re-Estimation wäre nicht möglich.
Pflichtfeld Annahmen pro Item. Ohne Annahmen ist Schätzung nicht reproduzierbar und nicht überprüfbar.
Items mit 8+ Ideal Days bleiben in der Liste, Schätzgenauigkeit fällt drastisch.
Items über 5 Ideal Days splitten oder als Spike vorschalten. Große Schätzungen haben zu viele Annahmen, Streuung wird unbeherrschbar.
Done-Signale, in unter einer Minute prüfbar
Zum Steckbrief für Zweck, ähnliche Methoden und Quellen — oder direkt zur nächsten Methode im Katalog.