---
title: "Projektzeiterfassung in Scrum und agilen Teams"
description: "Zeiterfassung in Scrum: Wie passt Stundenbuchung zu Sprints, Story Points und agilem Arbeiten?"
author: "Redaktion"
category: "projektzeiten"
language: "de-DE"
published_at: "2026-01-22"
canonical_url: "https://www.zeiterfassungsgesetz.de/ratgeber/projektzeiten/projektzeit-scrum-agile"
markdown_url: "https://www.zeiterfassungsgesetz.de/ratgeber/projektzeiten/projektzeit-scrum-agile.md"
image: "https://www.zeiterfassungsgesetz.de/images/articles/projektzeiten/projektzeit-scrum-agile.webp"
keywords: ["Projektzeit Scrum","agile Zeiterfassung","Sprint Zeit","Scrum Stunden","agile Teams Zeiterfassung"]
---

# 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 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

## 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

### Widerspricht Zeiterfassung dem agilen Manifest?

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.

### Sollen wir Story Points oder Stunden schätzen?

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.

### Wie vermeide ich, dass Zeiterfassung zu Kontrolle führt?

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.

### Wie detailliert sollte die Erfassung sein?

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.

### Kann ich Velocity aus Zeiterfassung berechnen?

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.

---

Weitere Inhalte: [KI-lesbarer Seitenindex](https://www.zeiterfassungsgesetz.de/llms.txt) · [HTML-Version](https://www.zeiterfassungsgesetz.de/ratgeber/projektzeiten/projektzeit-scrum-agile)