Kostenlose Vorlage für Projektstatusberichte für agile Teams

Agile Teams stoßen häufig auf dasselbe Kommunikationsproblem: Das Team verfügt bereits über ein Backlog, ein Board, ein Sprint-Ziel, Reviews und funktionierende Software, dennoch bitten Stakeholder weiterhin um eine prägnante Projektstatus-Präsentation. Der Fehler liegt meist nicht darin, die Präsentation zu erstellen. Der Fehler besteht darin, die Präsentation zu einer zweiten Wahrheit zu machen, sie als Ersatz für das Sprint Review zu nutzen oder sie zu einer Sammlung von Prozentwerten zu machen, die präzise aussehen, aber niemandem bei einer Entscheidung helfen.

Diese kostenlose Vorlage für Projektstatusberichte ist eine Folie-für-Folie-Inhaltsblaukopie, die Sie in PowerPoint oder Google Slides kopieren können. Sie ist für Scrum- und andere agile Teams konzipiert, die ein kurzes Update für Stakeholder benötigen, ohne so zu tun, als würden alle Teams dieselben Kennzahlen oder denselben Berichtszyklus verwenden. Der Schwerpunkt liegt auf verifizierten Fakten, kontextabhängigen Indikatoren, offenen Entscheidungen und konkreten nächsten Schritten.

Zunächst: Was ein agiler Statusbericht ist – und was nicht

Verifiziert: Scrum schreibt keine wöchentliche Statusbericht-Präsentation vor. Der aktuelle offizielle Scrum Guide definiert das Produkt-Backlog, das Sprint-Backlog, das Inkrement, deren Verpflichtungen und die Scrum-Ereignisse; eine Projektstatus-Präsentation ist keines dieser erforderlichen Artefakte oder Ereignisse. Der Guide besagt auch, dass das Sprint Review eine Arbeitssitzung zur Inspektion des Sprint-Ergebnisses und zur Entscheidung über zukünftige Anpassungen ist und dass das Team vermeiden sollte, es auf eine Präsentation zu beschränken. Sie können dies im offiziellen Scrum Guide nachlesen.

Nützliche Maßnahme: Behandeln Sie die Präsentation als Kommunikationsebene, nicht als paralleles Managementsystem. Ziehen Sie Fakten aus den vorhandenen Quellen des Teams – Produkt-Backlog, Sprint-Backlog, Inkrement, Release-Daten, Fehlerdaten, Risikoprotokoll und Entscheidungen – anstatt manuell einen zweiten Satz von Zahlen zu erfinden.

Kontextabhängig: Einige Organisationen benötigen ein wöchentliches Update für die Geschäftsführung; andere benötigen nur eine Zusammenfassung auf Release-Ebene oder einen monatlichen Portfolio-Bericht. Scrum selbst schreibt diesen Rhythmus nicht vor. Ein reguliertes Programm, ein Kundenvertrag, ein PMO oder eine Multi-Team-Initiative kann vernünftigerweise zusätzliche Berichterstattung über Scrum hinaus erfordern.

Nützliche Maßnahme: Wählen Sie die Berichterstattungsfrequenz basierend auf dem Entscheidungszyklus des Publikums. Wenn Führungskräfte wöchentlich Finanzierungs- oder Abhängigkeitsentscheidungen treffen, kann eine wöchentliche Zusammenfassung hilfreich sein. Wenn sich zwischen zweiwöchigen Sprints nichts Wesentliches ändert, erzeugt das Wiederholen derselben Präsentation alle paar Tage Berichterstattungsaufwand, ohne die Transparenz zu verbessern.

Kostenlose Vorlage für agile Projektstatus-Präsentationen

Die folgende Struktur mit acht Folien ist bewusst kompakt gehalten. Für ein kleines Produktteam benötigen Sie möglicherweise nur die Folien 1, 2, 4, 6 und 8. Für ein Programm mit externen Abhängigkeiten nutzen Sie alle acht. Ersetzen Sie jeden Beispiel-Platzhalter durch Daten aus Ihrem tatsächlichen Team.

Folie 1: Titel und Berichtszeitraum

Halten Sie die Eröffnungsfolie funktional. Ein nützlicher Titel ist „Projektstatusbericht — Checkout-Modernisierung — Sprint 14“, gefolgt vom Berichtsdatum und Teamnamen. Vermeiden Sie es, eine ganze Folie für Slogans oder dekorative Inhalte zu verwenden, wenn die Präsentation für ein zehminütiges Betriebsreview gedacht ist.

Nützliche Maßnahme: Fügen Sie den genauen Berichtszeitraum hinzu, z. B. „Sprint 14: 1.–14. September 2026“. Das macht jede Zahl in späteren Folien leichter interpretierbar und verhindert, dass Menschen Kennzahlen aus verschiedenen Perioden vergleichen.

Folie 2: Management-Status ohne Scheingenauigkeit

Eine einfache Management-Folie kann einen Gesamtstatus wie „Auf Kurs“, „Gefährdet“ oder „Abweichend“ enthalten, aber das Label benötigt einen genannten Grund. „Gefährdet, weil die Zertifizierung des Zahlungsanbieters vom 16. auf den 23. September verschoben wurde“ ist handlungsleitend. Ein roter Status ohne Erklärung ist es nicht.

Häufiges Missverständnis: Eine „80 % abgeschlossen“-Balkenanzeige ist nicht automatisch ein agiles Maß für den Fortschritt. Der offizielle Scrum Guide betont Empirismus und weist darauf hin, dass Praktiken wie Burn-downs, Burn-ups und kumulative Flows nützliche Prognosen sein können, aber nicht das ersetzen, was tatsächlich geschehen ist. Er besagt auch, dass in komplexen Umgebungen nur das, was bereits geschehen ist, für zukunftsorientierte Entscheidungen verwendet werden darf. Siehe den Sprint-Abschnitt des offiziellen Scrum Guide.

Nützliche Maßnahme: Wenn Sie einen Abschlussprozentsatz anzeigen, definieren Sie den Nenner. „39 von 50 geplanten Migrationsaufgaben abgeschlossen“ ist etwas anderes als „78 % des Kundenwerts geliefert“, und keines sollte das andere implizieren.

Folie 3: Ziel- und Ergebnisfortschritt

In Scrum ist das Sprint-Ziel das einzige Ziel für den Sprint, während das Produktziel das langfristige Ziel ist, auf das das Scrum-Team hinarbeitet. Das Sprint-Backlog enthält das Sprint-Ziel, ausgewählte Produkt-Backlog-Einträge und den umsetzbaren Lieferplan. Dies gibt dem Statusbericht ein besseres Ordnungsprinzip als „erledigte Aufgaben versus verbleibende Aufgaben“.

Eine gute Folie kann lauten:

• Produktziel: Kunden ermöglichen, den Checkout mit der neuen Zahlungsplattform abzuschließen.
• Aktuelles Sprint-Ziel: End-to-End-Autorisierungs- und Rückerstattungsflüsse in der Staging-Umgebung nachweisen.
• Nachweise in diesem Zeitraum: Der Autorisierungspfad hat die Definition of Done erfüllt; der Rückerstattungspfad bleibt durch Anbieter-Zugangsdaten blockiert.

Nützliche Maßnahme: Formulieren Sie den Folientitel als Ergebnisaussage, z. B. „Autorisierungsfluss abgeschlossen; Rückerstattungsvalidierung weiterhin blockiert“, anstatt „Sprint-Fortschritts-Update“. Ein Stakeholder sollte den Zustand verstehen, bevor er die Details liest.

Folie 4: Abgeschlossene Arbeit sollte abgeschlossene Arbeit bedeuten

Scrum bietet hier eine nützliche Grenze: Arbeit ist nicht Teil eines Inkrements, es sei denn, sie erfüllt die Definition of Done. Die Definition of Done schafft ein gemeinsames Verständnis des Qualitätszustands, der für abgeschlossene Arbeit erforderlich ist. Das bedeutet, dass eine Status-Präsentation vorsichtig mit Labels wie „fertig“, „beendet“ oder „geliefert“ umgehen sollte.

Nützliche Maßnahme: Trennen Sie drei Zustände, wenn sie relevant sind: „implementiert“, „erfüllt Definition of Done“ und „an Benutzer freigegeben“. Sie können zu unterschiedlichen Zeiten eintreten. Dies verhindert, dass Stakeholder „fertig“ hören und davon ausgehen, dass die Funktion bereits live ist.

Eine kompakte Folie für abgeschlossene Arbeit kann drei Spalten verwenden: Fertiges Inkrement, Nachweis und Benutzer-/Geschäftswirkung. Zum Beispiel: „Rückerstattungs-API-Integration — automatische Vertragstests bestanden — entfernt manuelle Rückerstattungsverarbeitung aus dem nächsten Pilotprojekt.“

Folie 5: Wählen Sie Kennzahlen für die Frage, nicht weil das Diagramm agil aussieht

Es gibt kein einzelnes verpflichtendes „agiles Diagramm“. Der Scrum Guide erwähnt Burn-downs, Burn-ups und kumulative Flows ausdrücklich als Praktiken, die für Prognosen nützlich sein können; er schreibt keines davon vor. Velocity ist auch nicht als erforderliche Scrum-Kennzahl definiert.

Nützliche Maßnahme: Wählen Sie den kleinsten Kennzahlensatz, der die Frage des Publikums beantwortet:

Unbekannt, bis Sie es messen: Eine höhere Velocity beweist nicht allein, dass das Team produktiver geworden ist oder mehr Kundenwert geliefert hat. Story-Point-Skalen sind teamspezifisch, Schätzpraktiken ändern sich und die Mischung der Arbeit ändert sich.

Nützliche Maßnahme: Wenn Sie Velocity anzeigen, kennzeichnen Sie sie als Planungssignal für dieses Team und kombinieren Sie sie mit einem Ergebnis, das Stakeholder tatsächlich interessiert.

Folie 6: Risiken und Blocker entscheidungsreif machen

Eine Risikoliste wird nützlich, wenn sie dem Publikum sagt, was passieren könnte und welche Reaktion erforderlich ist. „API-Problem“ ist zu vage. „Das Ratenlimit des Anbieters könnte den Abschluss des Lasttests bis zum 18. September verhindern; der Plattform-Leiter testet Caching; eine Erhöhung des Anbieter-Quotas wurde angefordert; eine Eskalation durch die Geschäftsführung ist bis Freitag erforderlich, wenn keine Antwort eingeht“ unterstützt Maßnahmen.

Nützliche Maßnahme: Geben Sie jedem großen Risiko fünf Felder: Risiko, Auswirkung, Verantwortlicher, Gegenmaßnahme und Entscheidungs-/Auslöserdatum. Beschränken Sie die Präsentation auf Risiken, die ein Ziel, ein Datum, Kosten, Umfang, Qualitätsniveau oder eine Abhängigkeit ändern könnten.

Folie 7: Entscheidungen und wesentliche Änderungen dokumentieren

Agile Pläne sollen sich anpassen, wenn mehr gelernt wird. Der Scrum Guide besagt, dass der Umfang während des Sprints mit dem Product Owner geklärt und neu verhandelt werden kann, solange das Sprint-Ziel nicht gefährdet ist. Daher ist ein geänderter Plan nicht automatisch ein Beweis für schlechte Ausführung.

Nützliche Maßnahme: Machen Sie Änderungen explizit. Schreiben Sie „Optionales Exportformat nach Kundentest entfernt; Kapazität auf Barrierefreiheitsfehler verlagert“, anstatt stillschweigend den Umfang zu ändern und Stakeholder zu überlassen, zu erraten, was passiert ist.

Ein kleines Entscheidungsprotokoll auf der Folie kann enthalten: Datum, Entscheidung, Grund, Verantwortlicher und Konsequenz. Dies ist besonders nützlich, wenn dieselbe Präsentation von Führungskräften überprüft wird, die nicht an den Arbeitssitzungen teilgenommen haben.

Folie 8: Enden Sie mit der nächsten Entscheidung, nicht mit einem generischen „Danke“

Die stärkste Abschlussfolie sagt dem Publikum, was als Nächstes passiert und ob sie etwas tun müssen. Nehmen Sie das nächste Sprint- oder Release-Ziel, ein bis drei kurzfristige Meilensteine und jede erforderliche Stakeholder-Entscheidung auf.

Nützliche Maßnahme: Enden Sie mit einem Satz, der umgesetzt werden kann: „Genehmigen Sie die zusätzliche Testumgebung bis zum 15. September, um das Pilotfenster im Oktober zu erhalten.“ Wenn keine Stakeholder-Aktion erforderlich ist, sagen Sie das: „Keine Eskalation angefordert; das Team arbeitet weiterhin am aktuellen Sprint-Ziel.“

Soll dies das Sprint Review ersetzen?

Nein. Dies ist eine der wichtigsten Unterscheidungen, die beibehalten werden muss. Der Scrum Guide besagt, dass das Sprint Review existiert, um das Sprint-Ergebnis zu inspizieren, den Fortschritt zum Produktziel zu diskutieren, Änderungen in der Umgebung zu berücksichtigen und über die nächsten Schritte zu kollaborieren. Es beschreibt das Sprint Review ausdrücklich als Arbeitssitzung und besagt, dass das Scrum-Team vermeiden sollte, es auf eine Präsentation zu beschränken.

Nützliche Maßnahme: Verwenden Sie die Status-Präsentation vor oder nach dem Sprint Review, wenn eine prägnante Management-Zusammenfassung wertvoll ist. Priorisieren Sie während des Reviews das tatsächliche Inkrement, die Stakeholder-Diskussion, Nachweise und Anpassungen gegenüber dem Vorlesen von Folien.

PowerPoint oder Google Slides?

Beide können diese Struktur unterstützen, aber „Template“ hat in PowerPoint eine spezifische Produktbedeutung. Microsoft dokumentiert, dass eine wiederverwendbare PowerPoint-Vorlage als .potx-Datei gespeichert werden kann und einen Folienmaster und Layouts enthalten kann. Microsoft weist auch darauf hin, dass das Erstellen einer PowerPoint-Vorlage die Desktop-Version erfordert, nicht PowerPoint für das Web. Siehe Microsofts offizielle Anweisungen für PowerPoint-Vorlagen.

Nützliche Maßnahme: Wenn Ihre Organisation Desktop-PowerPoint verwendet, verwandeln Sie die wiederholten Folienstrukturen – Managementzusammenfassung, Risikotabelle, Kennzahlen-Panel, Entscheidungsprotokoll – in Folienmaster-Layouts und speichern Sie das fertige Design als .potx-Datei.

Google definiert eine Slides-Vorlage als eine vordefinierte Sammlung, die Themen, Layouts, Hintergründe, Schriftarten, Farben und Platzhalterinhalte kombinieren kann. Google Slides ermöglicht es Benutzern auch, Layouts zu ändern und im Browser zusammenzuarbeiten. Siehe Googles offizielle Dokumentation zu Slides-Vorlagen und Layouts.

Nützliche Maßnahme: Wenn Echtzeit-Kollaboration wichtiger ist als eine lokale .potx-Datei, erstellen Sie die Acht-Folien-Struktur in Google Slides nach, behalten Sie eine saubere Masterkopie an einem gemeinsamen Ort und duplizieren Sie sie für jeden Berichtszeitraum.

Eine kopierfertige Ein-Folien-Management-Version

Wenn acht Folien zu viel sind, verwenden Sie dieses verdichtete Layout:

• Ziel: Welches Ergebnis versuchen wir zu erreichen?
• Status: Auf Kurs / Gefährdet / Abweichend, gefolgt von einem Satz, der erklärt, warum.
• Fertig: Zwei oder drei abgeschlossene, verifizierbare Ergebnisse.
• Nachweis: Eine aussagekräftige Kennzahl oder Beobachtung.
• Risiken: Die ein oder zwei wichtigsten Punkte, die den Plan ändern könnten.
• Entscheidung erforderlich: Was muss ein Stakeholder genehmigen, beantworten oder freischalten?
• Nächstes: Das nächste Ziel und der erwartete Kontrollpunkt.

Nützliche Maßnahme: Wenn ein Statusmeeting regelmäßig länger dauert als die Arbeit, die es klären soll, versuchen Sie die Ein-Folien-Version für den nächsten Berichtszyklus. Verschieben Sie Details in Links oder Anhang-Folien und halten Sie die Live-Diskussion auf Entscheidungen, Risiken und geänderte Annahmen fokussiert.

Finale Qualitätsprüfung vor dem Senden der Präsentation

Überprüfen Sie vor der Veröffentlichung eines agilen Projektstatusberichts jede Aussage gegen ihre Quelle. Eine einfache Checkliste reicht aus:

• Entspricht das angegebene Sprint-Ziel dem tatsächlichen Sprint-Backlog des Teams?
• Bedeutet „Fertig“, dass die Arbeit die Definition of Done des Teams erfüllt?
• Werden freigegebene Funktionen von abgeschlossenen, aber nicht freigegebenen Inkrementen unterschieden?
• Definiert jeder Prozentwert, was gezählt wird?
• Sind Prognosen als Prognosen gekennzeichnet, nicht als Zusagen?
• Sind Risiken Verantwortlichen mit einer Gegenmaßnahme oder einem Entscheidungspunkt zugewiesen?
• Sind geänderte Annahmen und Umfangsentscheidungen sichtbar?
• Macht die letzte Folie die nächste Aktion klar?

Eine gute agile Status-Präsentation versucht nicht zu beweisen, dass alles grün ist. Ihre Aufgabe ist es, die Realität leicht inspizierbar zu machen: welches Ziel das Team verfolgt, was tatsächlich abgeschlossen wurde, welche Nachweise existieren, was den Plan ändern könnte und welche Entscheidung als Nächstes ansteht. Verwenden Sie diese kostenlose Vorlage als Startstruktur und entfernen Sie dann jede Folie, die Ihrem spezifischen Publikum nicht hilft, den Fortschritt zu inspizieren oder eine bessere Entscheidung zu treffen.