Kostenlose Vorlage für Projektstatusberichte an agile Teams

Ein nützlicher Agile-Projektstatusbericht sollte es einem Stakeholder ermöglichen, vier Fragen schnell zu beantworten: Bewegen wir uns auf das Produktziel zu? Welchen nutzbaren Wert haben wir geliefert? Was gefährdet das nächste Ergebnis? Welche Entscheidung oder Hilfe wird jetzt benötigt? Wenn eine Präsentation diese Fragen nicht in wenigen Minuten beantworten kann, machen zusätzliche Diagramme sie in der Regel länger, aber nicht besser.

Für die meisten Agile-Teams reicht eine Status-Präsentation mit sieben Folien aus: Status auf einen Blick, Ziel und Ergebnisse, Fortschritt, Risiken und Hindernisse, Umfang und Änderungen, Qualität/Freigabebereitschaft sowie nächste Maßnahmen oder Entscheidungen. Die folgende Vorlage ist bewusst kompakt gehalten. Sie soll die Transparenz für Stakeholder verbessern, ersetzt aber nicht das Sprint Review, das Daily Scrum, das Produkt-Backlog oder andere Arbeitsartefakte.

Stand 11. September 2026 ist die aktuelle offizielle Scrum Guide-Ausgabe diejenige vom November 2020. Sie betont Transparenz, häufige Inspektion des Fortschritts hin zu vereinbarten Zielen und Anpassung, wenn sich Ergebnisse oder Bedingungen ändern. Sie besagt auch, dass das Sprint Review eine Arbeitssitzung ist, in der das Scrum-Team und die Stakeholder die Ergebnisse inspizieren und bestimmen, was als Nächstes zu tun ist – und nicht bloß eine Präsentation. Siehe den offiziellen Scrum Guide.

Was eine hochwertige Status-Präsentation erreichen sollte

Die Präsentation ist erfolgreich, wenn die Teilnehmer mit einem gemeinsamen Verständnis der Realität und einer kleinen Anzahl klarer Maßnahmen herausgehen. Sie ist nicht allein deshalb erfolgreich, weil jede Folie vollgepackt ist.

Dies entspricht dem Prinzip des Agile Manifests, dass funktionierende Software das primäre Maß für den Fortschritt ist. Für Teams, die etwas anderes als Software produzieren, nutzen Sie dieselbe Grundidee: Betonen Sie ein nutzbares, verifizierbares Inkrement oder Ergebnis anstelle bloßer Aktivität. Siehe die Prinzipien hinter dem Agile Manifest.

Kostenlose Vorlage für Agile-Projektstatusberichte: Struktur mit 7 Folien

Folie 1: Projektstatus auf einen Blick

Beginnen Sie mit den Informationen, die ein beschäftigter Stakeholder vor allem anderen benötigt:

• Produkt- oder Projektname
• Berichtszeitraum oder Sprint-Nummer
• Produktziel oder Hauptziel
• Sprint-Ziel
• Gesamtstatus mit kurzer Erklärung
• Die ein bis drei wichtigsten Risiken
• Ein Satz darüber, was sich seit dem letzten Bericht geändert hat

Wenn Sie den Rot/Gelb/Grün-Status verwenden, definieren Sie dessen Bedeutung. „Gelb“ könnte bedeuten, dass das Sprint-Ziel noch erreichbar ist, aber eine Abhängigkeit das Timing erheblich beeinflussen könnte. Eine Farbe ohne Kriterien wird subjektiv und kann Statusoptimismus fördern.

Qualitätsprüfung: Ein Stakeholder, der nur diese Folie liest, sollte die aktuelle Richtung und die wichtigste Sorge verstehen.

Folie 2: Ziel, Kundenergebnis und gelieferter Wert

Zeigen Sie, was das Team erreichen will und was sich für Nutzer, Kunden oder das Geschäft geändert hat. Diese Folie ist wertvoller als eine lange Liste „abgeschlossener Aufgaben“.

Eine einfache Struktur ist:

In Scrum muss ein Inkrement nutzbar sein und die Definition of Done erfüllen, bevor es als Teil des Inkrements gilt. Das ist ein besserer Anker für den Status als das Zählen teilweise abgeschlossener Backlog-Items, als hätten sie gleichen Wert geliefert. Der Scrum Guide definiert die Definition of Done als die formale Beschreibung des Zustands des Inkrements, wenn es die erforderlichen Qualitätsmerkmale des Produkts erfüllt.

Qualitätsprüfung: Unterscheiden Sie klar zwischen „fertig“, „in Arbeit“ und „geplant“. Beschreiben Sie Arbeit nicht als geliefert, wenn sie die Definition of Done des Teams nicht erfüllt hat.

Folie 3: Sprint-Fortschritt und Prognose

Verwenden Sie ein oder zwei Fortschrittsvisualisierungen nur, wenn sie bei einer Entscheidung helfen. Der Scrum Guide erkennt Praktiken wie Burn-downs, Burn-ups und kumulativen Fluss als nützliche Prognosetechniken an, weist aber ausdrücklich darauf hin, dass sie den Empirismus nicht ersetzen.

Nützliche Optionen sind:

• Burn-up-Diagramm: Hilfreich, wenn sich der Umfang ändert und Sie den abgeschlossenen Arbeit im Verhältnis zum Gesamtumfang zeigen möchten.
• Burn-down-Diagramm: Hilfreich zur Visualisierung der verbleibenden Arbeit innerhalb eines begrenzten Sprints oder einer Release-Prognose.
• Kumulativer Fluss: Hilfreich, wenn Sie wachsende Work-in-Progress oder einen Workflow-Engpass aufdecken müssen.
• Einfache Ergebnistabelle: Oft besser als ein Diagramm für kleine Teams oder Führungspersonen.

Vermeiden Sie es, Velocity nur hinzuzufügen, weil Agile-Präsentationen erwartungsgemäß ein Diagramm enthalten sollen. Der Scrum Guide definiert Velocity nicht als erforderliche Scrum-Metrik. Wenn Ihr Team sie für Prognosen nutzt, erklären Sie, was die Zahl darstellt, und vergleichen Sie sie mit der eigenen Team-Historie, anstatt sie als universellen Produktivitätswert zu behandeln.

Qualitätsprüfung: Das Diagramm sollte eine Frage beantworten. Wenn seine Entfernung das Verständnis oder die Entscheidung niemandes nicht ändern würde, entfernen Sie es.

Folie 4: Risiken, Hindernisse und Abhängigkeiten

Dies ist oft die entscheidungsrelevanteste Folie. Trennen Sie drei Konzepte:

• Risiko: Ein zukünftiges Ereignis oder eine Bedingung, die ein Problem verursachen kann.
• Hindernis: Etwas, das den Fortschritt derzeit blockiert.
• Abhängigkeit: Arbeit, Informationen oder Fähigkeiten, die von einem anderen Team, Anbieter, System oder Entscheidungsträger benötigt werden.

Verwenden Sie Spalten wie:

Scrum schätzt ausdrücklich Offenheit über Arbeit und Herausforderungen, und der Scrum Master ist dafür verantwortlich, Hindernisse für den Fortschritt des Teams zu beseitigen. Eine Status-Präsentation, die unbequeme Risiken versteckt, arbeitet gegen die Transparenz, die für eine nützliche Inspektion erforderlich ist.

Qualitätsprüfung: Jeder wesentliche Blocker sollte einen Verantwortlichen oder eine explizite Eskalationsanfrage haben. „Das Team überwacht“ ist für eine kritische Abhängigkeit selten ausreichend.

Folie 5: Umfangsänderungen und was das Team gelernt hat

Agile Statusberichte sollten nicht implizieren, dass der ursprüngliche Plan heilig ist. Der Scrum Guide besagt, dass der Umfang geklärt und mit dem Product Owner neu verhandelt werden kann, wenn mehr gelernt wird, solange das Sprint-Ziel nicht gefährdet ist.

Zeigen Sie Änderungen, die die Erwartungen der Stakeholder wesentlich beeinflussen:

• Neue Anforderung entdeckt
• Backlog-Item entfernt, weil es nicht mehr genug Wert beiträgt
• Technische Annahme widerlegt
• Abhängigkeit geändert
• Kundenfeedback führte zur Neupriorisierung

Verwenden Sie eine kurze Tabelle „Geändert / Warum / Auswirkung“. Dies macht die Anpassung sichtbar, ohne dass das Publikum zwei Backlog-Snapshots manuell vergleichen muss.

Qualitätsprüfung: Erklären Sie, ob eine Änderung das Ziel, die Prognose, die Kosten, die Qualität oder nur den Implementierungsansatz betrifft.

Folie 6: Qualität und Freigabebereitschaft

„Im Zeitplan“ reicht nicht aus, wenn die Qualität nachlässt. Nehmen Sie einige Qualitätssignale auf, die für das Produkt wichtig sind. Je nach Team könnten diese umfassen:

• Einhaltung der Definition of Done
• Offene kritische Defekte
• Gesundheit der automatisierten Tests
• Sicherheits- oder Barrierefreiheitsprüfungen
• Trend der Produktionsvorfälle
• Freigabe-Blocker
• Operative Bereitschaft

Füllen Sie die Folie nicht mit jeder verfügbaren Engineering-Metrik. Wählen Sie Beweise aus, die damit zusammenhängen, ob das Inkrement nutzbar ist und ob Stakeholder der Freigabeentscheidung vernünftigerweise vertrauen können.

Qualitätsprüfung: Wenn die Präsentation „grün“ anzeigt, während ein freigabeblockierender Defekt ungelöst bleibt, muss das Statusmodell geändert werden.

Folie 7: Entscheidungen, nächste Schritte und Verantwortliche

Enden Sie mit Maßnahmen, nicht mit einer generischen „Danke“-Folie. Eine einfache Tabelle funktioniert:

Qualitätsprüfung: Nach der Präsentation sollte keine Unklarheit darüber bestehen, wer die nächste extern sichtbare Maßnahme verantwortet.

Welche Metriken gehören in eine Agile-Statuspräsentation?

Verwenden Sie Metriken nur, wenn sie Inspektion und Anpassung unterstützen. Ein praktischer Auswahlrahmen ist:

Verwandeln Sie die Präsentation nicht in ein Scorecard von Vanity-Metriken. Abgeschlossene Story Points, Anzahl geschlossener Tickets oder Auslastung können in einem bestimmten Kontext gültige interne Signale sein, aber sie sind kein Ersatz für nutzbare Ergebnisse. Die Betonung des Agile Manifests auf funktionierende Software als primäres Maß für den Fortschritt ist hier ein nützlicher Leitfaden.

Wann eine Präsentation das falsche Werkzeug ist

Eine Präsentation ist nützlich, wenn das Publikum eine prägnante, periodische Synthese benötigt. Ändern Sie den Ansatz, wenn:

• Stakeholder Echtzeit-Betriebsdaten benötigen; verwenden Sie ein Live-Dashboard.
• Das Team die heutige Arbeit koordinieren muss; verwenden Sie das Daily Scrum und das aktuelle Sprint-Backlog.
• Das Publikum das tatsächliche Inkrement inspizieren muss; demonstrieren Sie es, anstatt es auf Folien zu beschreiben.
• Das Team diskutiert, warum sein Prozess versagt hat; verwenden Sie das Sprint Retrospective.
• Ein detailliertes Backlog-Ordering benötigt wird; arbeiten Sie direkt im Backlog oder im Produktmanagementsystem.

Der Scrum Guide ist besonders klar darin, dass das Sprint Review nicht auf eine Präsentation beschränkt sein sollte. Eine Projektstatus-Präsentation kann Stakeholder vorbereiten und den Kontext zusammenfassen, aber sie sollte die kollaborative Inspektion des Produkts und die Diskussion darüber, was als Nächstes zu tun ist, nicht ersetzen.

Wie oft sollten Sie die Präsentation aktualisieren?

Passen Sie den Berichtszyklus an die Entscheidungen an, die das Publikum treffen muss. Viele Teams aktualisieren den Status einmal pro Sprint, während Programme mit erheblichen Abhängigkeiten möglicherweise eine kürzere wöchentliche Zusammenfassung benötigen. Häufigeres Berichten ist nicht automatisch transparenter, wenn die Präsentation einfach die Daten von gestern wiederholt.

Eine nützliche Regel ist: Aktualisieren Sie, wenn die Informationen eine Stakeholder-Entscheidung, Prognose oder Risikoreaktion ändern können. Halten Sie das Quelldatum bei jeder Metrik sichtbar, die nicht live ist.

Designregeln, die die Lesbarkeit verbessern

PowerPoint unterstützt das Starten von einer vorbereiteten Vorlage sowie von einer leeren Präsentation, und Microsoft empfiehlt Vorlagen, wenn Sie eine konsistente Anordnung von Layout, Schriftarten, Farben und Effekten wünschen. Siehe Microsofts PowerPoint-Präsentationsanleitung.

Für eine Status-Präsentation:

• Verwenden Sie eine Botschaft pro Folie.
• Bevorzugen Sie kurze Tabellen und direkte Beschriftungen gegenüber dichten Absätzen.
• Zeigen Sie den Berichtszeitraum und das Datendatum an.
• Halten Sie Statusfarben konsistent und definieren Sie sie.
• Verwenden Sie großen Text, der im Besprechungsraum lesbar bleibt.
• Verlassen Sie sich nicht allein auf Farbe, um Risiken zu kommunizieren; fügen Sie Text oder Icons hinzu.
• Verlinken Sie auf das Quellsystem, wenn tiefere Details nützlich sind.

Wenn Sie die Präsentation wiederverwenden möchten, unterstützt Microsoft auch das Speichern einer angepassten Präsentation als PowerPoint-Vorlage (.potx), sodass dieselbe Struktur für zukünftige Berichte verwendet werden kann. Siehe Microsofts Anleitung zur Vorlagenerstellung.

Woran Sie erkennen, dass die Vorlage geändert werden muss

Behalten Sie dieselben Folien nicht ewig bei, nur weil die Präsentation gebrandet ist. Ändern Sie die Vorlage, wenn ihre Informationen die getroffenen Entscheidungen nicht mehr unterstützen.

Signale sind:

• Stakeholder fragen wiederholt nach denselben fehlenden Informationen.
• Folien werden über mehrere Sprints hinweg unverändert kopiert.
• Teams verbringen mehr Zeit mit Formatierung als mit der Diskussion von Risiken oder Ergebnissen.
• Metriken fördern unhilfreiches Verhalten, wie die Optimierung der Ticketanzahl statt des Werts.
• Risikoelemente bleiben rot ohne Verantwortlichen oder Maßnahme.
• Die Präsentation dupliziert ein Live-Dashboard, ohne Interpretation hinzuzufügen.
• Das Meeting wird zu einer Einweg-Präsentation statt zu Inspektion und Anpassung.

Eine nützliche Vorlage sollte den Berichtungsaufwand im Laufe der Zeit reduzieren, nicht ein zweites Projektmanagementsystem schaffen, das manuell gepflegt werden muss.

Grenzen dieser kostenlosen Statusbericht-Vorlage

Diese Struktur funktioniert gut für ein kleines Agile-Team, einen einzelnen Produktstrom oder eine Executive-Zusammenfassung einer größeren Initiative. Sie ist weniger geeignet, wenn ein Programm viele Produkte, regulierte Stage-Gates, vertragliche Earned-Value-Berichte, komplexe Portfolio-Finanzierung oder Dutzende von Teamübergreifenden Abhängigkeiten enthält. In diesen Fällen kann die Sieben-Folien-Präsentation die Executive-Zusammenfassung bleiben, aber detaillierte Governance sollte in den entsprechenden Quellsystemen und Programmsteuerungen leben.

Sie schreibt auch keinen universellen Satz von Agile-Metriken vor. Scrum ist bewusst leichtgewichtig, und der Scrum Guide weist darauf hin, dass Techniken und Taktiken je nach Kontext stark variieren können. Wählen Sie die kleinste Menge an Beweisen, die den tatsächlichen Zustand der Arbeit für gute Entscheidungen sichtbar genug macht.

Abschließende Qualitäts-Checkliste

• Das Produktziel und das Sprint-Ziel sind sichtbar.
• Gelieferter Wert wird von noch in Arbeit befindlicher Arbeit getrennt.
• Der Status wird durch Beweise gestützt, nicht nur durch Farbe.
• Prognosediagramme haben einen klaren Zweck.
• Risiken, Hindernisse und Abhängigkeiten werden unterschieden.
• Wesentliche Änderungen im Umfang oder in den Annahmen werden erklärt.
• Qualitäts- und Freigabebereitschaftsnachweise sind enthalten, wenn relevant.
• Jede angeforderte Entscheidung oder Eskalation hat einen Verantwortlichen und ein Datum.
• Die Präsentation ist prägnant genug, um diskutiert statt vorgelesen zu werden.
• Die Präsentation ergänzt – statt ersetzt – die Scrum-Events und Live-Artefakte des Teams.

Eine starke Agile-Projektstatus-Präsentation ist letztlich ein Entscheidungshilfsmittel. Sie macht die aktuelle Realität des Teams sichtbar, verbindet Fortschritt mit Zielen und nutzbaren Ergebnissen, deckt Risiken früh genug auf, um zu handeln, und endet mit klaren nächsten Schritten. Wenn die Präsentation dies mit fünf statt sieben Folien tut, verwenden Sie fünf. Wenn ein Live-Dashboard eine Folie überflüssig macht, entfernen Sie sie. Die Vorlage sollte Transparenz und Anpassung dienen – und nicht zu einer weiteren Zeremonie werden, die das Team füttern muss.