Kostenlose Vorlage für den agilen Projektplan mit Projektauftrag (Excel, Sheets, PDF)
Diese kostenlose Vorlage für den agilen Projektplan legt Ihr Projekt Sprint für Sprint an, mit Ziel, Epics oder Features, geplanten Story Points, Release-Punkten und Status für jeden Sprint, dazu ein einseitiger agiler Projektauftrag für Vision, Rollen und Arbeitsvereinbarungen. Laden Sie sie ohne Registrierung in Google Sheets, Excel oder PDF als Einsteiger-, Fortgeschrittenen- oder Expertenversion mit Rechenbeispiel herunter.
Das Wichtigste in Kürze
- Ein agiler Projektplan ist ein schlanker, regelmäßig aktualisierter Plan, der die Richtung vorgibt (Vision, Ziele, Sprints, Releases), ohne jedes Detail vorab festzulegen.
- Die Vorlage hat zwei Tabs: einen agilen Plan mit einer Zeile pro Sprint und einen Projektauftrag für Vision, Ziele, Rollen, Zeremonien, Definition of Done, Risiken und Randbedingungen.
- Planen Sie die nächsten ein oder zwei Sprints im Detail und spätere Sprints nur auf Epic-Ebene.
- Prognostizieren Sie mit der tatsächlichen Velocity Ihres Teams als Bandbreite, nicht als einzelnes Versprechen.
- Aktualisieren Sie den Plan nach jedem Sprint Review, damit er immer widerspiegelt, was geliefert und gelernt wurde.
Kostenloser Download · ohne Anmeldung
Vorlage für den agilen Projektplan herunterladen
Wählen Sie Stufe und Format: Google Sheets, Excel oder ein druckfertiges PDF. Die Tabellen enthalten Dropdowns, Formeln und Beispielzeilen, die Sie überschreiben können.
Die vollständige Vorlage mit allen Tabs, Dropdowns und Formeln.
Was ist ein agiler Projektplan?
Ein agiler Projektplan ist ein schlanker Plan für ein Projekt, das in kurzen Iterationen geliefert wird. Er legt Produktvision und Ziele, das Team, die geplanten Sprints mit jeweils einem Ziel, die darin erwarteten Epics oder Features und die angestrebten Releasetermine fest. Anders als ein traditioneller Plan wird er am Ende jedes Sprints überarbeitet, während das Team dazulernt.
Agile Teams planen durchaus; sie planen nur anders. Das Agilen Manifest schätzt „Reagieren auf Veränderung mehr als das Befolgen eines Plans“, was bedeutet, dass der Plan existiert, um Entscheidungen zu leiten, und nicht, um gegen Veränderungen verteidigt zu werden. Geplant wird wenig und oft, mit Details nur dort, wo sie nützlich sind.
In Scrum ist der Product Owner für das Product Backlog und dessen Prioritäten verantwortlich, daher verantwortet er meist den Inhalt des Plans. Ein Projektmanager, Delivery Lead oder Scrum Master pflegt ihn oft und teilt ihn mit den Stakeholdern.
Das Gesamtbild finden Sie in unserem Leitfaden zur Rolle des Projektplans in Agile.
Wo der Plan hingehört: Ebenen der agilen Planung
Agile Planung arbeitet auf mehreren Zeithorizonten, von der langfristigen Richtung bis zum nächsten Arbeitstag. Diese Vorlage liegt in der Mitte und verbindet die Roadmap mit einzelnen Sprints:
| Ebene | Horizont | Was es beantwortet | Wo es geplant wird |
|---|---|---|---|
| Vision | Lebensdauer des Produkts | Warum tun wir das? | Tab „Projektauftrag“ |
| Roadmap | Quartale bis ein Jahr | Welche Ergebnisse, in ungefähr welcher Reihenfolge? | Vorlage für die Produkt-Roadmap |
| Release-Plan | Wochen bis Monate | Was wird in jedem Release ausgeliefert? | Vorlage für einen Release-Plan |
| Agiler Projektplan | Die Sprints des Projekts | Wofür ist jeder Sprint da, und wann releasen wir? | Diese Vorlage |
| Sprint-Plan | Ein Sprint | Was tun wir in diesem Sprint, und wie? | Sprint-Planning-Vorlage |
| Tagesplan | Ein Tag | Was tun wir heute für das Sprint-Ziel? | Daily Scrum |
Kleine Projekte können diese Vorlage zugleich als Releaseplan und als Projektplan nutzen. Größere Produkte mit mehreren Teams führen meist eine separate Roadmap und einen separaten Releaseplan.
Was diese Vorlage für den agilen Projektplan enthält
Die Vorlage hat zwei Tabs mit Beispieldaten, die Sie mit Ihren eigenen überschreiben. Hier eine Live-Vorschau des ersten Tabs:
| Sprint | Termine | Sprint-Ziel | Epics / Features | Geplante Punkte | Release? | Status |
|---|---|---|---|---|---|---|
| Sprint 1 | 2. – 13. März | Nutzer können sich sicher anmelden | Login, Passwortzurücksetzung | 26 | Nein | Erledigt |
| Sprint 2 | 16. – 27. März | Nutzer können Rechnungen einsehen | Rechnungsliste, PDF-Download | 28 | Nein | In Arbeit |
| Sprint 3 | 30. März – 10. Apr. | Administratoren können Nutzer verwalten | Nutzerverwaltung, Exporte | 30 | Ja (R1) | Nicht begonnen |
| Sprint 4 | 13. – 24. Apr. | Hilfeinhalte in der App | Hilfecenter | 28 | Nein | Nicht begonnen |
Die Beispielzeilen sind nur Beispiele: Ersetzen Sie sie durch Ihre eigenen.
- Agiler Plan: Sprint, Termine, Sprint-Ziel, Epics / Features, Geplante Punkte, Release?, Status
- Projektauftrag: Punkt, Details
Tab „Agiler Plan“
- Sprint: der Name oder die Nummer des Sprints.
- Termine: Beginn und Ende des Sprints.
- Sprint-Ziel: das Ergebnis, das der Sprint erreichen soll, aus Sicht der Nutzer formuliert.
- Epics / Features: die wichtigsten Arbeitspakete, die für diesen Sprint geplant sind.
- Geplante Punkte: die Story Points, die das Team auf Basis der Velocity voraussichtlich abschließt.
- Release?: ob der Sprint mit einem Release endet, und mit welchem (zum Beispiel Ja (R1)).
- Status: ein Dropdown mit Nicht begonnen, In Bearbeitung, Pausiert, Blockiert und Erledigt.
Tab „Projektauftrag“
Ein schlanker agiler Projektauftrag mit Zeilen für Produktvision, Ziele und Erfolgskriterien, Product Owner, Scrum Master, Developer, Stakeholder, Sprintlänge (im Beispiel zwei Wochen), Zeremonien, Definition of Done, wesentliche Risiken sowie Budget oder Randbedingungen. Die Zeile zu den Zeremonien zeigt einen Beispielrhythmus: Sprint Planning am Montag, Daily Scrum um 09:30 sowie Review und Retrospektive am letzten Freitag.
Einsteiger-, Fortgeschrittenen- und Expertenversion
| Version | Leistungsumfang | Am besten für |
|---|---|---|
| Einsteiger | Der Tab „Agiler Plan“ mit fünf Spalten: Sprint, Termine, Sprint-Ziel, Epics / Features und Status | Kleine Teams und erste agile Projekte |
| Fortgeschritten | Beide Tabs: der vollständige agile Plan mit sieben Spalten und dem Status-Dropdown sowie der Projektauftrag | Die meisten Projekte |
| Experte | Die fortgeschrittene Vorlage plus ein Anleitungs-Tab, ein Dashboard, das Sprints nach Status zählt, Statusfarben (Erledigt grün, In Bearbeitung gelb, Blockiert rot) und ein Tab für die Änderungshistorie | Projekte, die an einen Sponsor, Lenkungsausschuss oder ein PMO berichten |
Die Vorlage enthält keine Formeln. Wenn Sie eine Summe der geplanten Punkte möchten, fügen Sie unter der Spalte „Geplante Punkte“ eine SUMME ein.
So erstellen Sie einen agilen Projektplan Schritt für Schritt
- Schreiben Sie zuerst den Projektauftrag. Vereinbaren Sie die Produktvision, zwei oder drei messbare Ziele, die Rollen, die Sprintlänge und die Zeiten der Zeremonien. Wer welche Rolle übernimmt, prüfen Sie in unserem Leitfaden zu Rollen im Scrum Team.
- Vereinbaren Sie die Definition of Done, damit alle wissen, was „fertig“ für jeden Eintrag bedeutet. Siehe unsere Definition of Done .
- Zerlegen Sie den Umfang in Epics und Features in Ihrer Vorlage für das Product Backlog, nach Wert geordnet.
- Schätzen Sie die Epics grob. Story Points oder T-Shirt-Größen reichen in dieser Phase; Sie verfeinern sie vor jedem Sprint.
- Ermitteln Sie Ihre erwartete Velocity. Nutzen Sie den jüngsten Durchschnitt des Teams oder bei einem neuen Team eine vorsichtige Annahme und berücksichtigen Sie Urlaube und andere Arbeit.
- Legen Sie die Sprints an. Fügen Sie eine Zeile pro Sprint mit Terminen hinzu und verteilen Sie dann die Epics in Backlog-Reihenfolge auf die Sprints, bis die geplanten Punkte jedes Sprints Ihrer Velocity entsprechen. Formulieren Sie für jeden ein Sprint-Ziel.
- Markieren Sie Release-Punkte in der Spalte „Release?“ und stimmen Sie sie mit den Stakeholdern ab.
- Überprüfen und prognostizieren Sie nach jedem Sprint Review neu. Aktualisieren Sie den Status, verschieben Sie unerledigte Arbeit und passen Sie spätere Sprints auf Basis der tatsächlichen Velocity und des Feedbacks an.
Tipps zur Tabelle
- Behalten Sie abgeschlossene Sprints im Plan. Sie sind Ihr Nachweis der tatsächlichen Lieferung und die Grundlage für die nächste Prognose.
- Filtern Sie nach Status, um den Stakeholdern nur die laufenden und die nächsten Sprints zu zeigen.
- Ergänzen Sie eine Spalte für die tatsächlichen Punkte, wenn Sie geplante und erledigte Arbeit Sprint für Sprint vergleichen möchten.
- Tragen Sie die wesentlichen Risiken in den Projektauftrag ein und managen Sie sie dann richtig in einem Vorlage für ein Risikoregister.
Beispiel für einen agilen Projektplan
Der Beispielplan der Vorlage gilt für ein Kundenportal, das in zweiwöchigen Sprints geliefert wird:
| Sprint | Sprint-Ziel | Epics / Features | Punkte | Release? | Status |
|---|---|---|---|---|---|
| Sprint 1 (2. bis 13. März) | Nutzer können sich sicher anmelden | Login, Passwortzurücksetzung | 26 | Nein | Erledigt |
| Sprint 2 (16. bis 27. März) | Nutzer können Rechnungen einsehen | Rechnungsliste, PDF-Download | 28 | Nein | In Arbeit |
| Sprint 3 (30. März bis 10. Apr.) | Administratoren können Nutzer verwalten | Nutzerverwaltung, Exporte | 30 | Ja (R1) | Nicht begonnen |
| Sprint 4 (13. bis 24. Apr.) | Hilfeinhalte in der App | Hilfecenter | 28 | Nein | Nicht begonnen |
- Jedes Sprint-Ziel beschreibt ein Ergebnis für die Nutzer, keine Aufgabenliste. Wenn sich einige Features verschieben, kann das Team das Ziel trotzdem erreichen.
- Das erste Release (R1) kommt nach Sprint 3, sobald Login, Rechnungen und Nutzerverwaltung ein nutzbares Produkt ergeben.
- Die geplanten Punkte bleiben nahe an der Velocity des Teams (etwa 28), sodass kein Sprint überladen ist.
- Sprint 4 ist nur auf Feature-Ebene geplant; die Details werden im Sprint Planning ausgearbeitet.
Ein gutes Sprint-Ziel formulieren
| Schwaches Sprint-Ziel | Stärkeres Sprint-Ziel |
|---|---|
| Stories 14 bis 22 abschließen | Kunden können ihre Rechnungen als PDF herunterladen |
| Am Reporting arbeiten | Manager sehen die wöchentlichen Umsätze nach Region auf einem Dashboard |
| Fehlerbehebung | Fehler im Checkout sinken so weit, dass Kunden die Zahlung ohne Support abschließen können |
Unsere Sprint Planning -Leitfaden erklärt, wie das Team zu Beginn jedes Sprints Ziel und Arbeit vereinbart.
Prognosen mit Velocity
Velocity ist die Zahl der Story Points, die ein Team in einem Sprint abschließt. Sobald Sie Daten aus drei bis fünf Sprints haben, nutzen Sie die Bandbreite statt nur des Durchschnitts. Wenn zum Beispiel die jüngsten Sprints eines Teams 24, 28 und 31 Punkte geliefert haben und 140 Punkte Arbeit übrig sind:
- Beim langsamsten Tempo (24 Punkte) dauert die Arbeit etwa 6 Sprints.
- Beim durchschnittlichen Tempo (etwa 28 Punkte) dauert sie 5 Sprints.
- Beim schnellsten Tempo (31 Punkte) dauert sie etwa 4,5 Sprints, in der Praxis also 5.
Sagen Sie den Stakeholdern „fünf bis sechs Sprints“ statt eines einzelnen Termins und verengen Sie die Bandbreite, während Sie dazulernen. Steht der Termin fest, drehen Sie die Frage um: Wie viel des Backlogs passt bis zu diesem Termin? Velocity ist ein Planungswerkzeug für das Team, kein Leistungsziel; Velocity zwischen Teams zu vergleichen ist sinnlos, weil jedes Team Punkte anders bemisst.
Agiler vs. traditioneller Projektplan
| Traditioneller Projektplan | Agiler Projektplan | |
|---|---|---|
| Was fest ist | Umfang, dann werden Zeit und Kosten geschätzt | Zeit (Sprints) und Team, mit flexiblem Umfang |
| Detaillierungsgrad | Für das gesamte Projekt vorab detailliert | Nur für die nächsten ein oder zwei Sprints detailliert |
| Planungseinheit | Aufgaben und Arbeitspakete | Epics, Features und User Stories |
| Fortschrittsmaß | Prozentualer Fertigstellungsgrad gegenüber einer Baseline | Gelieferte funktionierende Inkremente und erreichte Sprint-Ziele |
| Wann er sich ändert | Über formale Änderungssteuerung | Nach jedem Sprint Review |
| Typisches Format | Gantt-Diagramm und Terminplan | Plan Sprint für Sprint und Backlog |
Keines ist in jeder Situation besser. Feste, gut verstandene Arbeit passt zu einem traditionellen Projektplan-Vorlage; unsichere oder sich entwickelnde Produkte profitieren von einem agilen Plan.
Den Plan mit Kanban oder einem hybriden Ansatz nutzen
Kanban-Teams
Kanban kennt keine Sprints, doch Sie können diese Vorlage trotzdem nutzen. Ersetzen Sie jeden Sprint durch einen Planungszeitraum wie einen Monat oder ein Quartal, nutzen Sie die Spalte „Sprint-Ziel“ für das Ziel des Zeitraums und ersetzen Sie die geplanten Punkte durch den erwarteten Durchsatz (abgeschlossene Einträge pro Zeitraum). Unser Kanban-Planung -Leitfaden behandelt die Rhythmen ausführlicher.
Hybride Projekte
Viele Organisationen brauchen feste Meilensteine für Governance, Finanzierung oder Verträge, während das Lieferteam in Sprints arbeitet. Tragen Sie Ihre Projektmeilensteine in die Spalte „Release?“ oder als zusätzliche Zeilen ein und berichten Sie in jedem Sprint Review den Fortschritt im Vergleich dazu. Wenn Stakeholder eine Zeitachsenansicht erwarten, kann ein agiles Gantt-Diagramm auf Epic-Ebene diesen Plan ergänzen.
Häufige Fehler beim agilen Projektplan
- Jeden Sprint vorab im Detail planen. Das ist ein Wasserfallplan im agilen Gewand; Details über die nächsten ein oder zwei Sprints hinaus sind meist verschwendet.
- Sprint-Ziele, die Aufgabenlisten sind. Ein Ziel sollte ein Ergebnis beschreiben.
- Sprints überladen. Planen Sie nach Ihrer tatsächlichen Velocity, nicht nach der, die Sie sich erhoffen.
- Die Prognose als Zusage behandeln. Teilen Sie Bandbreiten und aktualisieren Sie sie in jedem Sprint.
- Den Projektauftrag auslassen. Ohne vereinbarte Vision und Definition of Done streiten Teams später über Prioritäten und Qualität.
- Den Plan veralten lassen. Wenn er nach dem Sprint Reviewnicht aktualisiert wird, verlieren die Stakeholder das Vertrauen in ihn.
- Nur den Output messen. Verfolgen Sie, ob Ziele und Ergebnisse erreicht werden, nicht nur, wie viele Punkte abgeschlossen wurden.
Verwandte Vorlagen und Leitfäden
Formulieren Sie Backlog-Einträge mit der Vorlage für User Stories, visualisieren Sie die Arbeit auf einem Kanban-Board-Vorlage und verbessern Sie jeden Sprint mit der Vorlage für Sprint-Retrospektiven. Den gesamten Prozess vom Kick-off bis zum Release finden Sie in So führen Sie ein agiles Projekt durch.
Projektplan-VorlageKostenlose Projektplan-Vorlage mit Zielen, Umfang, Lieferobjekten, Aufgaben, Verantwortlichen, Terminen und…Einsteiger · Fortgeschritten · Experte
Sprint-Planning-VorlageKostenlose Sprint-Planning-Vorlage mit Sprint-Ziel, Kapazität, ausgewählten Backlog-Einträgen, Story…Einsteiger · Fortgeschritten · Experte
Produkt-Roadmap-VorlageKostenlose Produkt-Roadmap-Vorlage mit Themen, Initiativen, Quartalen, Verantwortlichen und Status; auch…Einsteiger · Fortgeschritten · Experte
Vorlage für einen agilen Release-PlanKostenlose Vorlage für einen agilen Release-Plan: Releases, Sprints, Features, Story Points, Velocity…Einsteiger · Fortgeschritten · Experte
Sprint-Retrospektive-VorlageKostenlose Vorlage für Sprint-Retrospektiven: was gut lief, was verbessert werden soll, Ideen und Maßnahmen…Einsteiger · Fortgeschritten · Experte
Kanban-Board-VorlageKostenlose Kanban-Board-Vorlage mit den Spalten To Do, In Arbeit, Review und Done, WIP-Limits…Einsteiger · Fortgeschritten · ExperteHäufig gestellte Fragen
Was ist eine Vorlage für einen agilen Projektplan?
Eine Vorlage für einen agilen Projektplan ist ein schlanker Plan, der Vision, Ziele, Team, Sprints, Sprint-Ziele, Epics und Releases für ein agiles Projekt festlegt und dafür gedacht ist, in jedem Sprint aktualisiert zu werden.
Ist diese Vorlage für den agilen Projektplan kostenlos?
Ja. Die Vorlage für den agilen Projektplan steht kostenlos und ohne Registrierung in Google Sheets, Excel und PDF als Einsteiger-, Fortgeschrittenen- und Expertenversion zum Download bereit.
Brauchen agile Projekte einen Projektplan?
Ja. Auch agile Projekte planen, aber in kurzen Zyklen. Der Plan gibt Richtung und Release-Ziele vor und wird nach jedem Sprint überarbeitet, statt zu Beginn festgeschrieben zu werden.
Was sollte ein agiler Projektplan enthalten?
Produktvision und Ziele, Rollen, Sprintlänge und Zeremonien, die Definition of Done, nach Sprints geplante Epics oder Features, Sprint-Ziele, Release-Punkte, wesentliche Risiken und Randbedingungen.
Enthält die Vorlage einen agilen Projektauftrag?
Ja. Der Tab „Projektauftrag“ ist ein schlanker agiler Projektauftrag zu Vision, Zielen, Rollen, Stakeholdern, Sprintlänge, Zeremonien, Definition of Done, Risiken und Randbedingungen.
Wie unterscheidet sich ein agiler Projektplan von einem traditionellen Projektplan?
Ein traditioneller Projektplan legt den Umfang vorab fest und plant jede Aufgabe. Ein agiler Projektplan legt Zeit und Team fest, hält den Umfang flexibel und plant nur für die nächsten ein oder zwei Sprints im Detail.
Wie erstelle ich einen agilen Projektplan?
Schreiben Sie einen Projektauftrag, vereinbaren Sie die Definition of Done, zerlegen Sie den Umfang in Epics, schätzen Sie diese grob, ermitteln Sie die erwartete Velocity, verteilen Sie die Epics mit jeweils einem Ziel auf die Sprints, markieren Sie Releases und aktualisieren Sie den Plan nach jedem Sprint Review.
Wie oft sollte ich den agilen Projektplan aktualisieren?
Nach jedem Sprint Review, auf Basis dessen, was geliefert wurde, der tatsächlichen Velocity des Teams und des Feedbacks der Stakeholder.
Wer verantwortet den agilen Projektplan?
Der Product Owner verantwortet Prioritäten und Inhalt. Ein Projektmanager, Delivery Lead oder Scrum Master pflegt das Dokument oft und teilt es mit den Stakeholdern.
Kann ich die Vorlage für den agilen Projektplan mit Kanban nutzen?
Ja. Ersetzen Sie Sprints durch monatliche oder vierteljährliche Zeiträume, nutzen Sie die Zielspalte für das Ziel jedes Zeitraums und verfolgen Sie den Durchsatz statt Story Points.
Kann ich einen agilen Projektplan als Gantt-Diagramm darstellen?
Ja, auf Epic- oder Release-Ebene. Ein übergeordnetes agiles Gantt-Diagramm hilft Stakeholdern, die eine Zeitachse erwarten, während das Team mit dem Backlog arbeitet.
Was ist der Unterschied zwischen einem agilen Projektplan und einem Releaseplan?
Ein Releaseplan konzentriert sich darauf, was in jedem Release ausgeliefert wird. Ein agiler Projektplan deckt zudem Vision, Rollen, Zeremonien und Sprint-Ziele des Projekts ab. Kleine Projekte kombinieren oft beides in dieser Vorlage; größere nutzen eine separate Vorlage für den Releaseplan.
Was ist der Unterschied zwischen der Einsteiger-, Fortgeschrittenen- und Expertenversion der Vorlage für den agilen Projektplan?
Die Einsteigerversion ist der Tab „Agiler Plan“ mit fünf wesentlichen Spalten. Die Fortgeschrittenenversion hat beide Tabs, alle sieben Planspalten und das Status-Dropdown. Die Expertenversion ergänzt eine Anleitung, ein Dashboard, das Sprints nach Status zählt, Statusfarben und eine Änderungshistorie.