Projektzeiterfassung in Scrum und agilen Teams

Agile Methoden wie Scrum setzen auf Story Points statt Stunden. Trotzdem müssen Arbeitszeiten erfasst werden. Wie bringt man beides zusammen?

Das Wichtigste in Kürze

Story Points messen Komplexität, nicht Zeit
Zeiterfassung bleibt gesetzlich Pflicht
Beides kann parallel existieren
Zeitdaten helfen bei Kapazitätsplanung
Abrechnung oft stundenbasiert

Scrum und Zeiterfassung

Der vermeintliche Widerspruch

In Scrum wird oft gesagt:

"Wir schätzen in Story Points, nicht in Stunden"
"Zeiterfassung ist Micromanagement"
"Agile bedeutet Vertrauen"

Die Realität

Trotzdem brauchen Sie Zeiterfassung:

Grund	Erklärung
Gesetzliche Pflicht	Arbeitszeitgesetz
Kundenabrechnung	Oft nach Stunden
Kapazitätsplanung	Wie viel Zeit haben wir?
Projektbudget	Sind wir im Plan?
Personalkosten	Was kostet das Team?

Story Points vs. Stunden

Was sind Story Points?

Story Points messen die relative Komplexität:

Vergleich mit Referenz-Stories
Fibonacci-Sequenz (1, 2, 3, 5, 8, 13...)
Beinhaltet: Komplexität, Unsicherheit, Aufwand
Nicht direkt in Stunden umrechenbar

Warum trotzdem Zeiterfassung?

Aspekt	Story Points	Zeiterfassung
Zweck	Schätzung/Planung	Dokumentation
Wann	Vor der Arbeit	Während der Arbeit
Was	Komplexität	Tatsächlicher Aufwand
Nutzer	Team (Planung)	Abrechnung, HR, Compliance

Zeiterfassung für agile Teams

MyTimeTracker passt zu Scrum: Einfache Erfassung ohne Micromanagement.

Sofort einsatzbereit
DSGVO-konform
Keine Einrichtung nötig

Kostenlos testen

Zeiterfassung im Sprint

Wann buchen?

Optionen für das Team:

Ansatz	Vorteil	Nachteil
Täglich	Genau	Aufwändig
Am Sprint-Ende	Wenig Aufwand	Ungenau
Bei Story-Abschluss	Story-bezogen	Vergessen möglich
Wöchentlich	Kompromiss	Ungenau

Empfehlung

Tägliche Erfassung, aber einfach:

Nur Projekt und grobe Kategorie
Keine Detailbeschreibung jeder Aufgabe
Timer-Funktion nutzen
Am Ende des Tages kurz prüfen

Granularität der Erfassung

Zu grob

Buchung: "Sprint 5 - 40 Stunden"
→ Keine Aussagekraft

Sinnvoll

Projekt A - Feature X: 16h
Projekt A - Bugfixes: 8h
Projekt B - Spike: 4h
Meetings: 8h
Reviews/Retros: 4h

Zu fein

Ticket ABC-123: 45 Min.
Code Review ABC-124: 15 Min.
... (100 Einträge pro Sprint)

Velocity und Zeiterfassung

Velocity verstehen

Velocity = Story Points pro Sprint

Sprint 1: 24 SP
Sprint 2: 28 SP
Sprint 3: 26 SP
Durchschnitt: 26 SP/Sprint

Mit Zeiterfassung verknüpfen

Interessante Analyse:

Metrik	Berechnung
Stunden pro Story Point	Gesamtstunden / Story Points
Team-Kapazität	Verfügbare Stunden im Sprint
Produktivität	SP / verfügbare Stunden

Vorsicht bei Interpretation

Story Points sollen nicht in Stunden umgerechnet werden
Aber: Trends erkennen (wird Velocity bei gleicher Zeit besser?)
Team-interne Nutzung, nicht für Kontrolle

Auswertungen für Teams

MyTimeTracker liefert Insights – ohne Micromanagement.

Sofort einsatzbereit
DSGVO-konform
Keine Einrichtung nötig

14 Tage kostenlos testen

Abrechnung bei agilen Projekten

Modelle

Modell	Zeiterfassung relevant?
Festpreis	Intern ja, Abrechnung nein
Time & Material	Ja, Basis für Rechnung
Team as a Service	Oft pauschal pro Sprint
Agile Festpreis	Intern ja

Time & Material

Bei stundenbasierter Abrechnung:

Zeiterfassung ist Pflicht
Nachweis für Kunden
Story-Bezug oft gewünscht
Transparenz schafft Vertrauen

Retrospektive nutzen

Zeit-Themen in der Retro

Fragen für die Retrospektive:

Wie viel Zeit ging für Meetings drauf?
Wo wurden wir blockiert?
Stimmt unser Zeitgefühl mit den Daten überein?
Können wir Prozesse verschlanken?

Daten als Diskussionsgrundlage

Zeitdaten ermöglichen:

Objektive Diskussion statt Bauchgefühl
Trends über Sprints erkennen
Verbesserungen messbar machen

Tipps für agile Teams

Zeiterfassung positiv framen

Nicht: "Wir müssen kontrollieren, wie lange ihr braucht."

Sondern: "Wir brauchen die Daten für Abrechnung und Kapazitätsplanung."

Selbstorganisation

Team entscheidet:

Wie detailliert erfassen?
Wann erfassen?
Welche Kategorien?

Automation

Wo möglich automatisieren:

Integration mit Jira/Azure DevOps
Timer-Funktion in der App
Vorlagen für wiederkehrende Buchungen

Häufige Fragen

Nein. Das agile Manifest sagt nicht, dass man keine Zeit erfassen darf. Es betont, dass funktionierende Software wichtiger ist als Prozesse. Zeiterfassung ist eine Notwendigkeit (Gesetz, Abrechnung), kein Widerspruch zu Agilität.

Schätzen Sie in Story Points für die Sprint-Planung. Erfassen Sie Stunden für Abrechnung und Compliance. Das sind zwei verschiedene Dinge, die parallel existieren können.

Nutzen Sie Zeitdaten für Kapazitätsplanung und Prozessverbesserung, nicht für individuelle Leistungskontrolle. Transparenz im Team, Nutzung in Retrospektiven, und Fokus auf Team-Metriken statt Einzelpersonen.

So detailliert wie nötig, so einfach wie möglich. Erfassung auf Projektebene reicht oft. Bei Time & Material eventuell auf Story-Ebene. Vermeiden Sie Minutentracking für jede Aufgabe.

Nein, Velocity ist Story Points pro Sprint, nicht Stunden. Sie können aber analysieren, wie viele Stunden pro Story Point anfallen – als Team-interner Insight, nicht als Umrechnungsfaktor.

Fazit

Zeiterfassung und Scrum schließen sich nicht aus. Story Points dienen der Sprint-Planung, Zeiterfassung der Dokumentation und Abrechnung. Beide können parallel existieren. Wichtig ist, die Zeiterfassung einfach zu halten und nicht für Micromanagement zu missbrauchen. Nutzen Sie die Daten für Kapazitätsplanung und kontinuierliche Verbesserung – ganz im Sinne von Scrum.

Projektzeiterfassung in Scrum und agilen Teams