Ideale Tage in der agilen Schätzung: Der vollständige Leitfaden zur zeitbasierten Dimensionierung

Ein idealer Tag ist eine Schätzeinheit, die einen vollen Tag ununterbrochener, konzentrierter Arbeit an einer einzelnen Aufgabe darstellt - keine Meetings, keine E-Mails, kein Kontextwechsel, keine Unterbrechungen. Er beantwortet die Frage: „Wenn ich mich hinsetzen und an nichts anderem als dieser Aufgabe arbeiten könnte, wie viele Tage würde es dauern?" Ideale Tage gehören zu den intuitivsten Schätztechniken in Agile, weil sie eine Einheit verwenden, die jeder versteht - Zeit - und gleichzeitig anerkennen, dass reale Arbeitstage nie vollständig produktiv sind. Teams, die ideale Tage richtig einsetzen, erhalten präzise Prognosen ohne die Abstraktionshürde, die Story Points mit sich bringen.

Schnellantwort: Ideale Tage vs. Kalendertage vs. Story Points

Aspekt	Ideale Tage	Kalendertage	Story Points
Was gemessen wird	Tage ununterbrochener, konzentrierter Arbeit	Kalendertage von Beginn bis Abschluss	Relative Größe (Aufwand + Komplexität + Unsicherheit)
Unterbrechungen einbezogen?	Nein - geht von null Ablenkungen aus	Ja - umfasst den gesamten Overhead	Nicht zutreffend - abstrakte Einheit
Personenabhängig?	Teilweise - das Erfahrungsniveau beeinflusst die Schätzung	Ja - hängt davon ab, wer die Arbeit wann erledigt	Nein - das Team schätzt gemeinsam
Typische Umrechnung	1 idealer Tag = 1,5–2,0 Kalendertage	Direkte Kalendermessung	Keine Zeitumrechnung (nutzt Velocity)
Am besten geeignet für	Teams, die zeitbasiert denken	Projektmanagement und Terminverfolgung	Sprint-Kapazitätsplanung und Release-Prognosen
Größtes Risiko	Management interpretiert ideale Tage als Kalenderversprechen	Ignoriert den Unterschied zwischen Arbeiten und Warten	Punkte werden als Stunden behandelt

Was sind ideale Tage?

Ein idealer Tag ist ein Tag reiner, konzentrierter, ununterbrochener Arbeit. Keine Stand-ups, keine Slack-Nachrichten, kein Wechsel zwischen Aufgaben, keine E-Mails, kein Warten auf Code-Reviews - nur fokussierte, produktive Zeit an einem einzelnen Arbeitsstück.

Mike Cohn, der das Konzept in Agile Estimating and Planning populär gemacht hat, definiert einen idealen Tag als „die Zeit, die etwas dauert, wenn man alle Nebentätigkeiten abzieht." Es ist ein Gedankenexperiment: Wenn Sie sich in einen Raum einschließen könnten, mit allem, was Sie brauchen und ohne Ablenkungen - wie lange würde diese Aufgabe dauern?

Das Kernkonzept: Ununterbrochene Arbeit

Die Stärke idealer Tage liegt in der Trennung zweier Fragen, die traditionelle Schätzungen vermischen:

1. Wie viel Arbeit ist das? (beantwortet in idealen Tagen)
2. Wie lange wird es tatsächlich dauern? (beantwortet durch Anwendung eines Umrechnungsfaktors)

Wenn ein Entwickler sagt: „Das sind 3 ideale Tage Arbeit", beantwortet er Frage 1. Wenn das Team seinen Focus Factor von 0,6 anwendet, rechnet es in 5 Kalendertage um - und beantwortet damit Frage 2. Diese Trennung macht Schätzungen ehrlicher und Prognosen genauer.

Was ein idealer Tag ausschließt

Ein idealer Tag eliminiert alles, was nicht direkte produktive Arbeit ist:

• Meetings: Daily Scrums, Sprint Reviews, Retrospektiven, Planungssitzungen
• E-Mail und Nachrichten: Slack, Teams, E-Mail-Korrespondenz
• Kontextwechsel: Wechsel zwischen mehreren Aufgaben oder Projekten
• Administrative Aufgaben: Zeiterfassung, Statusberichte, Reisekostenabrechnungen
• Wartezeiten: Warten auf Code-Reviews, Deployments, Freigaben oder Abhängigkeiten
• Unterbrechungen: Ad-hoc-Fragen, Produktionsvorfälle, ungeplante Support-Anfragen
• Persönliche Zeit: Pausen, Mittagessen, private Erledigungen während der Arbeitszeit

Ideale Tage vs. Kalendertage

Der Unterschied zwischen idealen Tagen und Kalendertagen ist das Fundament, auf dem diese Schätztechnik funktioniert.

Kalendertage zählen jeden Tag vom Arbeitsbeginn bis zum Abschluss - einschließlich aller Meetings, Unterbrechungen, Wartezeiten und Multitasking, die in einem realen Arbeitstag vorkommen.

Ideale Tage zählen nur die produktive, konzentrierte Zeit.

Betrachten Sie dieses Beispiel: Ein Entwickler schätzt ein Feature auf 2 ideale Tage. So könnte die tatsächlich verstrichene Zeit aussehen:

Tag	Tatsächliche Arbeit am Feature	Andere Tätigkeiten
Montag	3 Stunden	2 Stunden Meetings, 1,5 Stunden E-Mail/Slack, 1,5 Stunden andere Aufgaben
Dienstag	4 Stunden	1 Stunde Daily Scrum + Refinement, 1 Stunde Code-Review für Kollegen, 2 Stunden andere Aufgaben
Mittwoch	2 Stunden	4 Stunden Sprint Review + Retrospektive, 2 Stunden andere Aufgaben
Donnerstag	5 Stunden	1 Stunde Meetings, 2 Stunden Reaktion auf Support-Anfragen
Gesamt	14 Stunden (1,75 ideale Tage)	~18 Stunden Feature-fremde Arbeit

Die 2 idealen Tage Arbeit haben fast 4 Kalendertage in Anspruch genommen. Das ist normal.

Der Overhead-Faktor

Die Lücke zwischen idealen und Kalendertagen entsteht durch organisatorischen Overhead - die projektfremde Arbeit, die einen realen Arbeitstag füllt. Untersuchungen zeigen durchgängig, dass Softwareentwickler nur 4–6 produktive Stunden pro 8-Stunden-Arbeitstag für ihre Hauptaufgaben aufwenden. Der Rest fließt in Meetings, Kommunikation, Kontextwechsel und administrative Arbeiten.

Häufige Overhead-Quellen und ihr typischer Zeitverbrauch:

Overhead-Quelle	Wochenstunden	% der 40-Stunden-Woche
Scrum-Zeremonien (Daily, Review, Retro, Planning)	3–5 Stunden	8–13 %
E-Mail und Nachrichten	3–5 Stunden	8–13 %
Meetings (nicht Scrum)	2–6 Stunden	5–15 %
Code-Reviews (Arbeit anderer prüfen)	2–4 Stunden	5–10 %
Erholung nach Kontextwechsel	2–3 Stunden	5–8 %
Administrative Aufgaben	1–2 Stunden	3–5 %
Ungeplante Unterbrechungen	2–4 Stunden	5–10 %
Gesamter Overhead	15–29 Stunden	38–73 %

Das bedeutet, ein typischer Entwickler hat 11–25 Stunden konzentrierter Arbeit pro Woche - ungefähr 1,4 bis 3,1 ideale Tage in einer 5-Tage-Arbeitswoche.

Typische Umrechnungsverhältnisse

Basierend auf Branchendaten sind hier typische Umrechnungsverhältnisse von idealen Tagen zu Kalendertagen:

Teamumgebung	Focus Factor	Ideal-zu-Kalender-Verhältnis	Ideale Tage pro Woche
Wenige Meetings, geringe Unterbrechungen	0,7–0,8	1 ideal = 1,25–1,4 Kalender	3,5–4,0
Durchschnittliches Scrum-Team	0,6–0,7	1 ideal = 1,4–1,7 Kalender	3,0–3,5
Hohe Meeting-Last	0,4–0,6	1 ideal = 1,7–2,5 Kalender	2,0–3,0
Mehrere Projekte, häufige Unterbrechungen	0,3–0,4	1 ideal = 2,5–3,3 Kalender	1,5–2,0

Ideale Tage vs. Story Points

Sowohl ideale Tage als auch Story Points sind valide Schätzansätze. Sie haben unterschiedliche Stärken, und die richtige Wahl hängt vom Kontext Ihres Teams ab.

Eigenschaft	Ideale Tage	Story Points
Intuitivität	Hoch - jeder versteht „Tage"	Anfangs niedrig - abstrakte Einheit erfordert Einarbeitung
Stakeholder-Kommunikation	Einfach - „3 Tage Arbeit" ist verständlich	Schwierig - „5 Punkte" muss übersetzt werden
Personenabhängigkeit	Moderat - der „ideale Tag" eines Senior-Entwicklers unterscheidet sich von dem eines Juniors	Keine - das Team schätzt als Einheit
Präzisionsrisiko	Mittel - Menschen projizieren auf Kalendererwartungen	Niedrig - abstrakte Einheiten widerstehen falscher Präzision
Risiko des Missbrauchs durch Management	Hoch - „Du hast 3 Tage gesagt, es hat 6 gedauert"	Mittel - schwerer, eine abstrakte Einheit als Waffe einzusetzen
Velocity-Tracking	Abgeschlossene ideale Tage pro Sprint	Abgeschlossene Story Points pro Sprint
Lernkurve	Minimal - Zeit ist universell verständlich	Moderat - braucht 3–5 Sprints zur Kalibrierung
Skala	Linear (1, 2, 3, 4, 5…)	Nicht-linear (Fibonacci: 1, 2, 3, 5, 8, 13…)

Wann ideale Tage verwenden

Ideale Tage funktionieren am besten, wenn:

• Das Team neu in Agile ist und einen intuitiven Einstiegspunkt für die Schätzung benötigt
• Stakeholder zeitbasierte Schätzungen benötigen und abstrakte Einheiten nicht akzeptieren
• Das Team von Wasserfall umstellt, wo stundenbasierte Schätzung die Norm war
• Arbeitseinheiten relativ gleichmäßig in der Komplexität sind und hauptsächlich im Aufwand variieren
• Das Team einen stabilen, vorhersehbaren Focus Factor hat, der die Umrechnung zuverlässig macht

Wann Story Points verwenden

Story Points funktionieren besser, wenn:

• Das Team gemischte Erfahrungsstufen hat und keine personenabhängigen Schätzungen möchte
• Das Management Zeitschätzungen in der Vergangenheit als Zusagen behandelt hat - abstrakte Einheiten schaffen einen Puffer
• Die Arbeit hohe Unsicherheit beinhaltet, bei der Komplexität und Risiko wichtiger sind als reiner Aufwand
• Sie Mikromanagement verhindern wollen - Story Points widerstehen dem „Du hast 3 Tage gesagt, warum hat es 5 gedauert?"
• Das Team reif genug ist, um mit abstrakter Schätzung zu arbeiten

Der Focus Factor (Load Factor)

Der Focus Factor (manchmal auch Load Factor oder Velocity-Faktor genannt) ist das Verhältnis, das ideale Zeit in Kalenderzeit umrechnet. Er ist die wichtigste Kennzahl, um ideale Tage für die Planung in der Praxis nutzbar zu machen.

So berechnen Sie den Focus Factor

Focus Factor = Abgeschlossene ideale Tage / Verfügbare Kalendertage

Beispiel: In einem 2-Wochen-Sprint (10 Arbeitstage) schließt ein Team von 5 Entwicklern Arbeit ab, die auf 21 ideale Tage geschätzt wurde.

• Verfügbare Kalendertage: 5 Entwickler x 10 Tage = 50 Personentage
• Abgeschlossene ideale Tage: 21 ideale Tage
• Focus Factor: 21 / 50 = 0,42

Das bedeutet, für jeden Kalendertag produziert jeder Entwickler etwa 0,42 ideale Tage konzentrierter Arbeit. Der Rest fließt in Overhead.

Typische Focus-Factor-Bereiche

Focus Factor	Was es bedeutet	Typische Umgebung
0,8+	Außergewöhnlich - fast die gesamte Zeit ist produktiv	Selten; Solo-Entwickler oder Hackathon-Bedingungen
0,6–0,7	Gut - das Team hat geschützte Fokuszeiten	Reifes Scrum-Team mit minimaler Meeting-Last
0,4–0,6	Durchschnittlich - typischer organisatorischer Overhead	Standard-Unternehmensumgebung
0,3–0,4	Niedrig - ausgeprägte Meeting-/Multitasking-Kultur	Mehrere Projekte, häufige Unterbrechungen
Unter 0,3	Problematisch - mehr Overhead als produktive Arbeit	Dysfunktionale Umgebung, die Intervention erfordert

Ihren Focus Factor verbessern

Wenn Ihr Focus Factor unter 0,5 liegt, erwägen Sie diese Verbesserungen:

• Meetings reduzieren: Prüfen Sie alle wiederkehrenden Meetings; streichen Sie solche ohne klare Ergebnisse
• Fokusblöcke schützen: Führen Sie „meetingfreie" Zeiträume ein (z. B. Vormittage) für konzentriertes Arbeiten
• Multitasking begrenzen: Weisen Sie Entwicklern jeweils nur ein Projekt zu; Kontextwechsel zerstören Produktivität
• Unterbrechungen bündeln: Bestimmen Sie einen rotierenden „Unterbrechungs-Beauftragten", der den Rest des Teams abschirmt
• Administrative Aufgaben automatisieren: Reduzieren Sie den Zeitaufwand für Statusberichte, Zeiterfassung und manuelle Prozesse
• Code-Reviews straffen: Legen Sie SLAs für die Review-Bearbeitungszeit fest (z. B. innerhalb von 4 Stunden), um Wartezeiten zu verringern

In idealen Tagen schätzen: Schritt für Schritt

Schritt 1: Definieren Sie, was „ideal" für Ihr Team bedeutet

Vor Ihrer ersten Schätzsitzung sollten Sie sich darauf einigen, was ein idealer Tag umfasst. Beinhaltet er nur das Programmieren? Oder auch das Schreiben von Tests, die Aktualisierung der Dokumentation und das Deployment? Die meisten Teams definieren einen idealen Tag als die gesamte Arbeit, die nötig ist, um die Definition of Done zu erfüllen - aber ohne Meetings, Unterbrechungen oder Wartezeiten.

Schritt 2: Referenzaufgaben festlegen

Wählen Sie 3–5 abgeschlossene Aufgaben als Referenzpunkte. Zum Beispiel:

Referenzaufgabe	Ideale Tage	Warum dieser Wert
Konfigurations-Toggle hinzufügen	0,5	Einfache Änderung, eine Datei, minimales Testen
Neues Formular mit Validierung erstellen	1,5	Moderater Frontend-Aufwand, Unit-Tests, Integrationstest
REST-API-Endpunkt mit Authentifizierung erstellen	3	Backend-Logik, Authentifizierung, Tests, Dokumentation
Drittanbieter-Zahlungs-API integrieren	5	Externe Abhängigkeit, Fehlerbehandlung, Sicherheitsprüfung, umfangreiche Tests
Datenbankschema mit Migration neu gestalten	8	Komplexe Änderungen, Migrationsskripte, Regressionstests, Rollback-Plan

Schritt 3: Durch Vergleich schätzen

Vergleichen Sie jede neue Aufgabe mit Ihren Referenzen: „Ist das mehr oder weniger Arbeit als der 3-ideale-Tage-API-Endpunkt?" Dies ist relative Schätzung mit Zeit als Einheit - der gleiche kognitive Vorteil wie bei Story Points, aber mit einer intuitiveren Skala.

Schritt 4: Planning Poker mit idealen-Tage-Karten verwenden

Führen Sie Planning Poker mit idealen Tageswerten statt Fibonacci-Zahlen durch. Übliche Kartenwerte: 0,5, 1, 1,5, 2, 3, 5, 8, 13. Gleichzeitiges Aufdecken verhindert Anker-Effekte.

Schritt 5: Signifikante Abweichungen besprechen

Wenn Schätzungen um mehr als das Doppelte auseinandergehen (z. B. eine Person sagt 2 ideale Tage und eine andere 5), ist die Diskussion Pflicht. Fragen Sie: „Welche Arbeit berücksichtigst du, die ich nicht sehe?" oder „Welchen Ansatz nimmst du an?"

Schritt 6: Die Konsensschätzung festhalten

Dokumentieren Sie die vereinbarte Schätzung in idealen Tagen beim Product-Backlog-Element. Halten Sie alle Annahmen fest, die die Schätzung beeinflusst haben (z. B. „geht davon aus, dass die vorhandene Auth-Bibliothek wiederverwendet werden kann").

Schritt 7: Ist-Werte zur Kalibrierung erfassen

Notieren Sie nach Abschluss der Arbeit, wie viele ideale Tage sie tatsächlich gedauert hat (nicht Kalendertage - tatsächlich konzentrierte Arbeitszeit). Vergleichen Sie dies mit der Schätzung in den Sprint Retrospektiven, um die zukünftige Genauigkeit zu verbessern.

Ideale Tage in Kalendertage umrechnen

Die Grundformel

Kalendertage = Ideale Tage / Focus Factor

Wenn eine Aufgabe auf 4 ideale Tage geschätzt wird und der Focus Factor Ihres Teams 0,6 beträgt:

Kalendertage = 4 / 0,6 = 6,7 Kalendertage (ungefähr 7 Arbeitstage, also 1,4 Wochen)

Für die Sprint-Kapazität auf Teamebene:

Sprint-Kapazität (ideale Tage) = Teamgröße x Sprint-Länge (Tage) x Focus Factor

Ein Team von 5 Entwicklern in einem 2-Wochen-Sprint (10 Arbeitstage) mit einem Focus Factor von 0,6:

Sprint-Kapazität = 5 x 10 x 0,6 = 30 ideale Tage

Das bedeutet, das Team kann pro Sprint ungefähr 30 ideale Tage an Arbeit übernehmen.

Team-Velocity in idealen Tagen

Genau wie die Story-Point-Velocity stabilisiert sich die Velocity in idealen Tagen über die Zeit und wird zum primären Planungsinput:

Sprint	Geplante ideale Tage	Abgeschlossene ideale Tage	Gleitender Durchschnitt
Sprint 1	28	22	22,0
Sprint 2	24	26	24,0
Sprint 3	25	23	23,7
Sprint 4	24	25	24,0
Sprint 5	24	24	24,0
Sprint 6	24	25	24,2

Nach 6 Sprints hat sich die Velocity dieses Teams bei ungefähr 24 idealen Tagen pro Sprint stabilisiert. Sie sollten zukünftige Sprints um diese Zahl herum planen und Backlog-Elemente auswählen, die in der Summe ungefähr 24 ideale Tage ergeben.

Vorteile und Nachteile idealer Tage

Vorteile	Nachteile
Intuitiv - jeder versteht „Tage"	Stakeholder verwechseln ideale Tage mit Kalendertagen
Leicht gegenüber nicht-technischen Stakeholdern zu erklären	Provoziert „Warum haben 3 ideale Tage 2 Wochen gedauert?"-Druck
Geringere Lernkurve als Story Points	Personenabhängig - Senior- und Junior-Entwickler schätzen unterschiedlich
Funktioniert gut für Teams, die von Wasserfall umstellen	Versuchung, direkt in Kalenderversprechen umzurechnen
Natürliche Verbindung zur Kalenderplanung	Erfasst Komplexität und Unsicherheit nicht so gut wie Story Points
Leichter in Aufgaben-Schätzungen zu zerlegen	Kann zu individueller Nachverfolgung führen („Wie viele ideale Tage hast du geschafft?")
Ermöglicht unkomplizierte Kapazitätsberechnung	Focus Factor variiert von Sprint zu Sprint und erzeugt Prognoseschwankungen
Hilft Overhead-Probleme zu erkennen (niedriger Focus Factor)	Teams unterschätzen möglicherweise, weil sie vergessen, dass Overhead ausgeschlossen ist

Wann ideale Tage vs. andere Techniken verwenden

Situation	Beste Technik	Warum
Neues agiles Team, erste 3–4 Sprints	Ideale Tage	Intuitiv, geringe Lernkurve, sofort einsetzbar
Reifes Scrum-Team mit stabiler Velocity	Story Points	Bessere Abstraktion, widersteht Management-Missbrauch
Dimensionierung auf Roadmap-Ebene (50+ Elemente)	T-Shirt-Größen	Schnell, geringer Overhead, ausreichende Granularität für Planungshorizonte
Aufgabenzerlegung im Sprint Planning	Ideale Stunden	Granular genug für Aufgabenzuweisung ohne Über-Präzision
Stakeholder-Kommunikation über Zeitpläne	Ideale Tage + Focus Factor	Übersetzt sich natürlich in „Wie lange wird das dauern?"
Teamübergreifender Vergleich	Weder ideale Tage noch Story Points	Verwenden Sie Durchsatz (abgeschlossene Elemente pro Sprint)
Hochunsichere Forschungs- oder Innovationsarbeit	Story Points oder T-Shirt-Größen	Ideale Tage suggerieren falsche Präzision bei unsicherer Arbeit
Support-/Wartungsteams mit einheitlichen Aufgaben	Durchsatzzählung	Zählen Sie abgeschlossene Elemente; Schätzung bringt keinen Mehrwert

Branchenbeispiele: Ideale Tage in der Praxis

SaaS-Produktteam

Ein 7-köpfiges SaaS-Team verwendet ideale Tage für das Sprint Planning mit einem stabilen Focus Factor von 0,65. Ihre Sprint-Kapazität beträgt 7 x 10 x 0,65 = 45,5 ideale Tage pro 2-Wochen-Sprint. Sie pflegen Referenzaufgaben, die auf ihren Tech-Stack kalibriert sind: 0,5 ideale Tage für eine Konfigurationsänderung, 2 ideale Tage für ein Standardfeature, 5 ideale Tage für eine größere Integration. Ihre Umrechnung in Kalenderzeit ist zuverlässig, da das Team kaum personelle Wechsel und konstanten Overhead hat.

Team für Gesundheitssoftware

Ein Gesundheitssoftware-Team, das unter HIPAA-Compliance arbeitet, verwendet ideale Tage mit einem angepassten Focus Factor von 0,45 - niedriger als der Durchschnitt, weil Compliance-Dokumentation, Sicherheitsüberprüfungen und Audit-Protokollierung zusätzlichen Overhead erzeugen, den andere Teams nicht haben. Ein Feature, das auf 3 ideale Tage geschätzt wird, dauert ungefähr 6,7 Kalendertage. Sie fügen explizit 1–2 ideale Tage zu jeder Schätzung hinzu, die geschützte Gesundheitsinformationen (PHI) betrifft, um die Verschlüsselungsverifizierung, Zugriffskontrolltests und die Vervollständigung der Compliance-Checkliste zu berücksichtigen.

Finanzdienstleistungsteam

Ein Fintech-Team verwendet ideale Tage für seine Kernbanking-Plattform. Ihr Focus Factor sinkt während der regulatorischen Prüfungszeiträume (vierteljährlich) auf 0,35, liegt aber normalerweise bei 0,6. Sie pflegen zwei Focus Factors und wechseln während der Planung je nach Überschneidung des Sprints mit Prüfungszyklen zwischen ihnen. Dieser Dual-Faktor-Ansatz verbesserte ihre Prognosegenauigkeit innerhalb von 6 Monaten von 55 % auf 82 %.

E-Commerce-Team

Ein E-Commerce-Team mit saisonalen Traffic-Spitzen verwendet ideale Tage kombiniert mit einer „Hochsaisonkorrektur". Während der Black-Friday-Vorbereitung (September–November) sinkt ihr Focus Factor von 0,6 auf 0,4, weil Entwickler viel Zeit für Performance-Tests, Lasttests und Produktionssupport aufwenden. Sie planen weniger ideale Tage für neue Features in diesen Monaten und kommunizieren die reduzierte Kapazität drei Monate im Voraus an die Produkt-Stakeholder.

Team für Regierungsaufträge

Ein Software-Team im öffentlichen Sektor verwendet ideale Tage, weil ihre Auftraggeber zeitbasierte Schätzungen für Projektangebote verlangen. Sie schätzen in idealen Tagen, wenden einen Focus Factor von 0,5 an (unter Berücksichtigung von Sicherheitsüberprüfungsverfahren, Dokumentationsanforderungen und mehrstufigen Genehmigungsworkflows) und präsentieren Kalendertag-Schätzungen gegenüber der Auftragsbehörde. Sie fügen den umgerechneten Schätzungen eine 20 %-ige Managementreserve für unvorhergesehene Compliance-Anforderungen hinzu.

EdTech-Startup

Ein kleines EdTech-Team von 4 Entwicklern verwendet ideale Tage, weil Story Points für ihre Größe zu abstrakt sind. Ihr Focus Factor ist mit 0,7 hoch, da sie wenige Meetings und eine flache Organisationsstruktur haben. Sie schätzen Features in Halbtags-Schritten (0,5, 1,0, 1,5, 2,0 usw.) und verfolgen die Velocity als gesamte ideale Tage pro Woche statt pro Sprint, da sie Continuous Delivery ohne Sprint-Grenzen praktizieren.

Reifegradmodell für die Schätzung mit idealen Tagen

Stufe 1: Erste Einführung (Sprints 1–4)

Zeitrahmen: Erste 1–2 Monate

Merkmale:

• Das Team verwechselt ideale Tage mit Kalendertagen
• Der Focus Factor ist unbekannt - Schätzungen verfehlen durchgehend das Ziel
• Entwickler schätzen basierend auf persönlicher Leistungsfähigkeit statt auf Teamdurchschnitt
• Stakeholder interpretieren „3 ideale Tage" als „bis Mittwoch fertig"

Worauf man sich konzentrieren sollte:

• Klar definieren, was ein idealer Tag einschließt und ausschließt
• Tatsächliche Fokuszeit über 2–3 Sprints erfassen, um einen Basis-Focus-Factor zu ermitteln
• Bei jeder Schätzsitzung Referenzaufgaben verwenden
• Den Unterschied zwischen idealen und Kalendertagen gegenüber Stakeholdern überdeutlich kommunizieren

Stufe 2: Kalibrierung (Sprints 5–10)

Zeitrahmen: Monate 2–5

Merkmale:

• Der Focus Factor bildet sich aus historischen Daten heraus (noch schwankend)
• Das Team beginnt, unter Verwendung von Referenzen konsistent zu schätzen
• Einige Elemente überraschen noch - typischerweise solche mit versteckter Komplexität
• Stakeholder beginnen, die Umrechnung von ideal zu Kalender zu verstehen

Worauf man sich konzentrieren sollte:

• Schätzungen mit Ist-Werten in jeder Sprint Retrospektive vergleichen
• Muster identifizieren: „Wir unterschätzen regelmäßig Aufgaben mit Datenbankmigrationen"
• Velocity (abgeschlossene ideale Tage pro Sprint) für die Kapazitätsplanung nutzen
• Den Focus Factor vierteljährlich basierend auf gesammelten Daten verfeinern

Stufe 3: Zuverlässig (Sprints 11–20)

Zeitrahmen: Monate 5–10

Merkmale:

• Der Focus Factor ist innerhalb eines Bereichs von 10–15 % stabil
• Schätzsitzungen sind effizient - die meisten Elemente konvergieren in unter 3 Minuten
• Die Sprint-Abschlussquote übersteigt 85 % (geplante vs. abgeschlossene Elemente)
• Das Team kann zuverlässig 2–3 Sprints vorausplanen

Worauf man sich konzentrieren sollte:

• Velocity-Bereiche (Best Case, Durchschnitt, Worst Case) für die Release-Planung verwenden
• Focus-Factor-Trends beobachten - wenn er sinkt, Ursachen untersuchen
• Neue Teammitglieder mit dem Referenzaufgaben-Katalog einarbeiten
• Überlegen, ob ideale Tage dem Team noch dienen oder ob ein Wechsel zu Story Points Mehrwert brächte

Stufe 4: Optimiert (Sprint 20+)

Zeitrahmen: 10+ Monate

Merkmale:

• Schätzung nimmt minimale Zeit in Anspruch - das Team einigt sich oft ohne Diskussion
• Prognosegenauigkeit liegt innerhalb von 10–15 % für die Sprint-Planung
• Der Focus Factor ist gut verstanden und wird aktiv gesteuert
• Das Team erwägt möglicherweise #NoEstimates oder durchsatzbasierte Prognosen für ausgereifte, einheitliche Arbeitsströme

Worauf man sich konzentrieren sollte:

• Monte-Carlo-Simulation für probabilistische Release-Prognosen verwenden
• Schätzungsaufwand nur auf hochunsichere Elemente konzentrieren
• Den Focus Factor aktiv durch organisatorische Änderungen verbessern (Meeting-Last reduzieren, Tooling verbessern)
• Strategien zur Focus-Factor-Verbesserung mit anderen Teams in der Organisation teilen

Häufige Fehler bei der Verwendung idealer Tage

Fehler Nr. 1: Ideale Tage als Kalenderversprechen behandeln

Problem: Ein Entwickler sagt: „Das sind 3 ideale Tage" und der Projektmanager trägt „Fällig: Mittwoch" in den Zeitplan ein.

Warum das schädlich ist: Es ignoriert Overhead, Meetings, Unterbrechungen und Multitasking. Die 3 idealen Tage werden in einer typischen Umgebung 5–7 Kalendertage dauern - und jetzt ist der Entwickler ab Tag 4 „im Verzug".

Lösung: Wenden Sie immer den Focus Factor an, bevor Sie Zeitpläne kommunizieren. Schulen Sie Stakeholder: „3 ideale Tage bei unserem Focus Factor von 0,6 bedeuten ungefähr 5 Kalendertage."

Prävention: Teilen Sie niemals rohe ideale-Tage-Schätzungen außerhalb des Teams. Rechnen Sie immer zuerst in Kalendertage um.

Fehler Nr. 2: Den Focus Factor ignorieren

Problem: Das Team schätzt in idealen Tagen, berechnet oder verfolgt aber nie seinen Focus Factor. Sie planen 40 ideale Tage in einen 2-Wochen-Sprint, weil „wir 5 Leute und 10 Tage haben."

Warum das schädlich ist: 40 ideale Tage setzen einen Focus Factor von 0,8 voraus - unrealistisch für nahezu jedes Team. Der Sprint wird chronisch überlastet sein.

Lösung: Messen Sie den Focus Factor empirisch über 3–4 Sprints. Verwenden Sie den gemessenen Wert, nicht eine optimistische Annahme.

Prävention: Verfolgen Sie abgeschlossene ideale Tage pro Sprint und berechnen Sie den Focus Factor nach jedem Sprint.

Fehler Nr. 3: Individuelle Schätzung

Problem: Das Team fragt: „Wie lange würdest DU dafür brauchen?" statt „Wie viele ideale Tage Arbeit stecken darin?"

Warum das schädlich ist: Schätzungen werden personenabhängig. Wenn der Senior-Entwickler 2 ideale Tage schätzt, aber ein Junior-Entwickler die Arbeit übernimmt, ist die Schätzung falsch.

Lösung: Schätzen Sie basierend auf einem „typischen Teammitglied" - nicht der schnellsten oder langsamsten Person. Wenn die Qualifikationsniveaus stark variieren, verwenden Sie die Durchschnittsfähigkeit des Teams als Basis.

Prävention: Formulieren Sie die Frage als „Wie viele ideale Tage Arbeit stecken in dieser Aufgabe?" - nicht „Wie lange würdest du dafür brauchen?"

Fehler Nr. 4: Halbe Tage nicht berücksichtigen

Problem: Das Team rundet alle Schätzungen auf ganze Tage, wodurch Granularität verloren geht. Eine 4-Stunden-Aufgabe wird zu „1 idealer Tag."

Warum das schädlich ist: Überschätzung auf Aufgabenebene summiert sich. Wenn 10 Aufgaben jeweils 0,5 ideale Tage sind, aber auf 1,0 geschätzt werden, wird die Sprint-Kapazität durch Phantomarbeit verbraucht.

Lösung: Erlauben Sie Halbtags-Schritte (0,5, 1,0, 1,5, 2,0 usw.). Das bietet ausreichende Granularität ohne falsche Präzision.

Prävention: Nehmen Sie 0,5 als kleinste Schätzeinheit in Ihr Planning-Poker-Deck auf.

Fehler Nr. 5: Vergessen, bei Umfangsänderungen neu zu schätzen

Problem: Eine Story, die auf 2 ideale Tage geschätzt wurde, erhält während des Sprints zusätzliche Akzeptanzkriterien, aber die Schätzung bleibt bei 2.

Warum das schädlich ist: Die Velocity-Daten des Teams werden unzuverlässig, da der geschätzte Aufwand den tatsächlichen Aufwand nicht mehr widerspiegelt.

Lösung: Schätzen Sie neu, wenn sich der Umfang wesentlich ändert. Wenn die ursprüngliche 2-ideale-Tage-Story jetzt eine neue Anforderung beinhaltet, die 1,5 Tage Arbeit hinzufügt, aktualisieren Sie die Schätzung auf 3,5.

Prävention: Melden Sie Umfangsänderungen im Daily Scrum und schätzen Sie neu, bevor Sie sich zum erweiterten Umfang verpflichten.

Fehler Nr. 6: Ideale Tage für große Epics verwenden

Problem: Jemand schätzt: „Dieses Epic hat 45 ideale Tage" ohne es aufzuteilen.

Warum das schädlich ist: Große Schätzungen haben enorme Unsicherheit. Eine 45-ideale-Tage-Schätzung könnte tatsächlich 30 oder 80 sein - die Fehlermarge ist für die Planung inakzeptabel.

Lösung: Zerlegen Sie Epics in Stories von jeweils 0,5–5 idealen Tagen, bevor Sie schätzen. Summieren Sie die Story-Schätzungen für das Epic-Gesamtergebnis.

Prävention: Legen Sie eine Aufteilungsschwelle fest: Jedes Element über 5–8 ideale Tage muss vor der Schätzung zerlegt werden.

Fehler Nr. 7: Annehmen, dass der Focus Factor konstant ist

Problem: Das Team berechnet in Sprint 5 einen Focus Factor von 0,6 und verwendet ihn unverändert für die nächsten 20 Sprints.

Warum das schädlich ist: Der Focus Factor ändert sich mit der Teamzusammensetzung, der Meeting-Last, organisatorischen Änderungen und saisonalen Faktoren. Ein veralteter Faktor erzeugt ungenaue Prognosen.

Lösung: Berechnen Sie den Focus Factor in jedem Sprint neu. Verwenden Sie einen gleitenden Durchschnitt der letzten 4–6 Sprints statt des Werts eines einzelnen Sprints.

Prävention: Nehmen Sie die Focus-Factor-Überprüfung als regelmäßigen Datenpunkt in die Sprint Retrospektive auf.

Fehler Nr. 8: Ideale Tage teamübergreifend vergleichen

Problem: Das Management sagt: „Team A schafft 30 ideale Tage pro Sprint, aber Team B nur 20. Team B muss sich verbessern."

Warum das schädlich ist: Verschiedene Teams haben unterschiedliche Focus Factors, unterschiedliche Definitionen von „ideal", unterschiedliche Arbeitstypen und unterschiedliche Overhead-Niveaus. 30 ideale Tage von Team A und 20 von Team B könnten identische tatsächliche Leistung darstellen.

Lösung: Wenn teamübergreifender Vergleich nötig ist, verwenden Sie Durchsatz (abgeschlossene Elemente pro Sprint) oder Zykluszeit - das sind objektive Kennzahlen, die von der Schätzmethodik unabhängig sind.

Prävention: Berichten Sie Velocity in idealen Tagen nur innerhalb des Teams. Verwenden Sie Durchsatzmetriken für teamübergreifende und organisationsweite Berichterstattung.

Fehler Nr. 9: Ideale Tage und Kalendertage in derselben Unterhaltung mischen

Problem: Während des Sprint Plannings werden einige Elemente in idealen Tagen und andere in Kalendertagen geschätzt. „Das sind 2 ideale Tage, und jenes sollte ungefähr 3 Tage dauern."

Warum das schädlich ist: Die zweite Schätzung ist mehrdeutig - sind „3 Tage" ideal oder Kalender? Das Mischen von Einheiten erzeugt Verwirrung, inkonsistente Planung und unzuverlässige Velocity-Daten.

Lösung: Wählen Sie eine Einheit und verwenden Sie sie konsequent. Wenn Sie in idealen Tagen schätzen, ist jedes Element in idealen Tagen. Rechnen Sie separat in Kalendertage um für die externe Kommunikation.

Prävention: Verwenden Sie ideale-Tage-Planning-Poker-Karten, um konsistente Einheiten während der Schätzsitzungen zu erzwingen.

Fehler Nr. 10: Das Konzept neuen Teammitgliedern nicht erklären

Problem: Ein neuer Entwickler kommt hinzu und schätzt „1 idealer Tag" im Sinne von „Ich bin morgen damit fertig" - ohne den Unterschied zwischen ideal und Kalender zu verstehen.

Warum das schädlich ist: Seine Schätzungen werden systematisch niedriger ausfallen als die des restlichen Teams, was die Velocity verzerrt und Planungsprobleme verursacht.

Lösung: Machen Sie jedes neue Teammitglied mit dem Schätzansatz des Teams vertraut: was ideale Tage bedeuten, wie der Focus Factor ist und wie Referenzaufgaben verwendet werden.

Prävention: Nehmen Sie die Schätzmethodik in die Onboarding-Dokumentation des Teams auf. Lassen Sie neue Mitglieder 2–3 Schätzsitzungen beobachten, bevor sie eigene Schätzungen abgeben.

Ideale Tage im Sprint Planning

Während des Sprint Plannings bieten ideale Tage ein unkompliziertes Kapazitätsmodell:

1. Verfügbare Kapazität berechnen:

Teammitglied	Verfügbare Tage	Focus Factor	Verfügbare ideale Tage
Entwickler A	10 (vollständiger Sprint)	0,6	6,0
Entwickler B	8 (2 Tage Urlaub)	0,6	4,8
Entwickler C	10 (vollständiger Sprint)	0,6	6,0
Entwickler D	10 (vollständiger Sprint)	0,6	6,0
Entwickler E	5 (halb in anderem Projekt)	0,6	3,0
Gesamt	43 Personentage		25,8 ideale Tage

2. Backlog-Elemente bis zur Kapazitätsgrenze auswählen:

Ziehen Sie Elemente von oben aus dem priorisierten Product Backlog, bis die Gesamtschätzung in idealen Tagen sich der Teamkapazität nähert (aber sie nicht überschreitet). Lassen Sie einen Puffer von 10–15 % für ungeplante Arbeiten.

Ziel ideale Tage für diesen Sprint: 25,8 x 0,85 (Puffer) = ~22 ideale Tage

3. Elemente in Aufgaben zerlegen (optional):

Manche Teams zerlegen Stories während des Sprint Plannings in Aufgaben, die in idealen Stunden geschätzt werden. Eine 3-ideale-Tage-Story könnte sich aufteilen in: Design (4 ideale Stunden), Implementierung (12 ideale Stunden), Testen (4 ideale Stunden), Code-Review (2 ideale Stunden), Dokumentation (2 ideale Stunden) = 24 ideale Stunden = 3 ideale Tage.

4. Gegen Velocity validieren:

Gleichen Sie die geplanten idealen Tage mit der historischen Velocity des Teams ab. Wenn Ihre durchschnittliche Velocity 24 ideale Tage beträgt und Sie 22 planen, liegen Sie im richtigen Bereich. Wenn Sie 30 planen, stimmt etwas nicht - entweder sind die Schätzungen zu optimistisch oder Sie überladen den Sprint.

Fazit

Ideale Tage schlagen die Brücke zwischen abstrakter Schätzung und kalenderbasierter Planung. Sie verwenden eine Einheit, die jeder versteht - Zeit - und erkennen dabei ehrlich an, dass ein „Arbeitstag" und ein „Kalendertag" nicht dasselbe sind. Der Focus Factor macht ideale Tage praxistauglich: Er wandelt optimistische, unterbrechungsfreie Schätzungen in realistische, planbare Prognosen um.

Zentrale Erkenntnisse:

1. Ein idealer Tag repräsentiert einen vollen Tag konzentrierter, ununterbrochener Arbeit - keine Meetings, keine E-Mails, kein Kontextwechsel
2. Der Focus Factor (typischerweise 0,4–0,7) rechnet ideale Tage in Kalendertage um - verfolgen und wenden Sie ihn immer an
3. Ideale Tage sind intuitiver als Story Points, tragen aber ein höheres Risiko, als Kalenderversprechen fehlinterpretiert zu werden
4. Teilen Sie niemals rohe ideale-Tage-Schätzungen außerhalb des Teams - rechnen Sie immer zuerst in Kalendertage um
5. Schätzen Sie basierend auf der Fähigkeit eines „typischen Teammitglieds", nicht der schnellsten oder langsamsten Person
6. Verwenden Sie Referenzaufgaben (0,5 bis 8 ideale Tage), um alle Schätzungen durch relativen Vergleich zu verankern
7. Verfolgen Sie die Velocity in idealen Tagen pro Sprint - sie stabilisiert sich nach 4–6 Sprints und wird zum primären Planungsinput
8. Ideale Tage eignen sich am besten für Teams, die neu in Agile sind, für den Übergang von Wasserfall und für Umgebungen, in denen Stakeholder zeitbasierte Schätzungen benötigen
9. Erwägen Sie den Übergang zu Story Points, sobald das Team reift und Managementdruck bei Zeitschätzungen zum Problem wird
10. Der Focus Factor selbst ist ein Diagnosewerkzeug - ein niedriger Focus Factor signalisiert organisatorische Dysfunktionen, die es zu beheben lohnt

Häufig gestellte Fragen (FAQs)