Sprintplanungs-Vorlage
Lade eine kostenlose Sprintplanungs-Vorlage mit Sprintziel, Umfang, Kapazität, Abhängigkeiten und Checkliste für Excel oder Google Sheets herunter.
Viele Teams sprechen intern von einer Sprint Planning Vorlage. Lade die CSV herunter, gehe die Checkliste vor dem Termin durch und nutze die Struktur später in Scrumbuiss weiter, wenn Sprintziel, Kapazität und Abhängigkeiten direkt im laufenden Workflow sichtbar bleiben sollen.
Was diese Sprintplanungs-Vorlage abdeckt
Diese Punkte helfen Teams dabei, Sprintplanung nicht nur als Meeting, sondern als belastbaren Startpunkt für den Sprint zu nutzen.
- ✓ Sprintziel, Commitments, Owner und Lieferhinweise in einem gemeinsamen Planungsblatt
- ✓ Kapazitätscheck mit Urlauben, Supportlast, Meetings und realistischer Verfügbarkeit vor dem Commitment
- ✓ Abhängigkeiten, Freigaben, Risiken und Blocker sichtbar, bevor der Sprint startet
- ✓ Kostenloser CSV-Download mit ausgefülltem deutschen B2B-Beispiel und Follow-up-Checkliste
Wann diese Vorlage am meisten hilft
Sie ist besonders stark, wenn Teams Kapazität, Abhängigkeiten, Freigaben und saubere Nachbereitung zusammen betrachten müssen statt nur Story Points zu verschieben.
- Nutze die Vorlage vor jeder Sprintplanung, wenn das Team das Meeting mit einem klaren Ziel, einem realistischen Umfang und eindeutig benannten Verantwortlichkeiten verlassen soll.
- Nutze sie, wenn Software-Teams neben Feature-Arbeit auch Support, Freigaben, Reviews oder operative Pflichttermine berücksichtigen müssen und reine Velocity deshalb zu kurz greift.
- Nutze sie, wenn Abhängigkeiten zu anderen Teams, Fachbereichen, QA oder Produktfreigaben regelmäßig erst mitten im Sprint sichtbar werden und dann Commitments kippen.
- Nutze sie, wenn ihr Backlog Refinement, Sprintplanung und tägliche Umsetzung klar trennen wollt, damit nicht jede offene Frage bis in den Sprintstart hineinrutscht.
Was in der Vorlage enthalten ist
Die Struktur ist schlank genug für eine echte Sprintplanung, aber vollständig genug, um die typischen Lücken zwischen Planung und Umsetzung sichtbar zu machen.
Was in eine gute Sprintplanung gehört
Jedes Feld sollte eine praktische Frage beantworten: Warum ist der Sprint wertvoll, was passt wirklich hinein, wer trägt Verantwortung und was muss direkt nach dem Meeting passieren?
Sprintziel
Formuliere ein Ergebnis, das den Wert des Sprints erklärt, statt nur die Liste geplanter Tickets zu wiederholen. So lassen sich Scope-Entscheidungen leichter begründen.
Ausgewählte Arbeit
Liste die Stories, Tasks oder Arbeitspakete auf, die tatsächlich in den Sprint sollen, damit Commitment und spätere Änderungen auf derselben Entscheidungsbasis beruhen.
Owner und Mitwirkende
Benenne die Hauptverantwortung je Element und halte fest, wer für Reviews, Freigaben oder Zuarbeit zusätzlich gebraucht wird.
Schätzung und Lieferhinweise
Erfasse Story Points, Stunden oder eine andere Planungseinheit plus kurze Hinweise, die Einfluss auf Reihenfolge, Risiko oder Testaufwand haben.
Kapazität und feste Last
Ziehe Urlaub, Support, Meetings, Rufbereitschaften und andere fixe Verpflichtungen ab, bevor das Team den Umfang bestätigt.
Abhängigkeiten und Freigaben
Dokumentiere technische Abhängigkeiten, externe Zuarbeit, QA-Fenster oder fachliche Freigaben, damit nicht erst nach Sprintstart sichtbar wird, was das Team nicht alleine liefern kann.
Risiken und Fallbacks
Halte die zwei bis drei wahrscheinlichsten Kipp-Punkte fest und vereinbare den ersten Gegenzug, falls Scope, Kapazität oder Timing ins Rutschen geraten.
Definition of Done
Schreibe klar auf, wann Arbeit wirklich als erledigt zählt, inklusive Review, Tests, Demo, Dokumentation oder Deployment-Schritt.
Ausgefülltes Sprintplanungs-Beispiel
Dieses Beispiel zeigt, wie ein deutsches B2B-Software-Team Sprintziel, Kapazität, Abhängigkeiten, Risiken und Follow-ups in einer verständlichen Planung zusammenführt.
Sprintziel
Für ein B2B-Reporting-Modul soll das Team im Sprint einen filterbaren Export für Kundenadministratoren live bringen, damit Monatsberichte ohne manuelle CSV-Nacharbeit erstellt werden können.
Geplanter Umfang
Im Sprint liegen vier Arbeitspakete: Export-API fertigstellen, UI-Filter bauen, QA-Testfälle für Rollenrechte ergänzen und das interne Support-Playbook für den Rollout aktualisieren. Nicht im Sprint: neue Diagrammtypen und die mobile Optimierung.
Kapazität des Teams
Fünf Personen haben zusammen 42 verfügbare Arbeitstage. Davon gehen 4 Tage auf Urlaub, 3 Tage auf Supportrotation, 2 Tage auf feste Review-Termine und 1 Tag auf Release-Vorbereitung. Die Planungsbasis liegt damit realistisch bei 32 Sprint-Tagen statt bei der Nominalkapazität.
Abhängigkeiten und Freigaben
Produkt muss die finalen Exportfelder bis Dienstag freigeben, QA braucht bis Mittwoch Zugriff auf die Staging-Daten, und das Customer-Success-Team liefert bis Donnerstag den finalen Wortlaut für den Hilfehinweis im Exportdialog.
Risiken und Fallback
Das größte Risiko ist eine verzögerte Freigabe der Rollenlogik. Fallback: Export zunächst nur für Admin-Rollen freischalten und das erweiterte Rollenmodell in den nächsten Sprint verschieben. Zweites Risiko: erhöhte Supportlast. Fallback: Supportfenster im Team neu verteilen und ein niedriger priorisiertes UI-Polishing aus dem Sprint nehmen.
Definition of Done
Ein Element gilt erst als fertig, wenn Code Review, automatisierte Tests, manueller Rechte-Check, Staging-Demo mit Product Owner und aktualisierte Supportnotiz abgeschlossen sind.
Direkt nach dem Planning
Der finale Sprintplan wird innerhalb von 30 Minuten veröffentlicht, alle Abhängigkeiten erhalten einen Owner mit Termin, und die offenen Freigaben werden noch am selben Tag aktiv nachverfolgt, statt erst im Daily wieder aufzutauchen.
Checkliste für vor, während und nach dem Planning
Nutze diese Punkte, damit Sprintplanung nicht bei der Scope-Auswahl endet, sondern in einen klaren Umsetzungsstart übergeht.
- Schärfe die Sprint-Kandidaten vor dem Termin, damit das Team nicht im Planning erst Grundsatzfragen aus dem Backlog Refinement nachholen muss.
- Bestätige pro Person die reale Verfügbarkeit inklusive Urlaub, Support, Meetings, Rufbereitschaft und anderer Pflichtlast.
- Lege ein Sprintziel fest, bevor ihr über den gesamten Umfang diskutiert, damit Prioritäten und Kürzungen an einem Ergebnis ausgerichtet bleiben.
- Prüfe jede größere Story gegen Abhängigkeiten, Freigaben, Testfenster und externe Zuarbeit, solange die relevanten Personen noch greifbar sind.
- Stelle sicher, dass jedes Commitment einen Owner, eine Schätzung und eine verständliche Definition of Done hat.
- Dokumentiere die wenigen kritischsten Risiken samt Fallback, statt erst bei der ersten Störung hektisch Umfang herauszunehmen.
- Veröffentliche den finalen Sprintplan noch am selben Tag und starte offene Follow-ups unmittelbar nach dem Termin.
Häufige Fehler in der Sprintplanung
Diese Muster sorgen dafür, dass Sprintplanung sauber aussieht, aber schon nach dem ersten Daily an Realität verliert.
- Das Planning mit einer Ticketliste zu beginnen, statt mit einem Sprintziel, wodurch später jede Scope-Diskussion wieder bei null startet.
- Nominale Teamgröße mit realer Kapazität zu verwechseln und Support, Meetings, Freigaben oder Ausfälle nicht abzuziehen.
- Backlog Refinement und Sprintplanung zu vermischen, bis im Planning noch unklare Anforderungen, fehlende Akzeptanzkriterien und Grundsatzfragen gelöst werden müssen.
- Abhängigkeiten nur zu benennen, aber ohne Owner, Zieltermin oder Eskalationsweg offenzulassen.
- Nach dem Meeting keinen sauberen Publish- und Follow-up-Schritt zu haben, sodass der Sprintplan in Notizen bleibt und der Kontext am ersten Tag schon auseinanderläuft.
So nutzt du die Vorlage im Arbeitsalltag
Der Ablauf trennt Refinement, Sprintplanung und tägliche Umsetzung sauber voneinander und macht den Übergang zwischen ihnen sichtbar.
Sprintziel vor dem Scope festziehen
Formuliere zuerst das Ergebnis, das der Sprint liefern soll. Nutze dieses Ziel dann als Filter für Scope, Priorität und spätere Kürzungen, statt nur die längste Ticketliste zu sortieren.
Mit realer Kapazität planen
Ziehe Verfügbarkeit, Support, Meetings und andere feste Last bewusst ab. Die Vorlage ist dann am wertvollsten, wenn sie das Team vor überoptimistischen Commitments schützt.
Abhängigkeiten veröffentlichen und nachhalten
Halte fest, wer welche Freigabe, Zuarbeit oder Blocker-Auflösung bis wann liefern muss, und veröffentliche den finalen Plan direkt nach dem Termin als gemeinsame Referenz für den Sprintstart.
Passende Funktionen für danach
Diese Seiten zeigen, wie aus einer statischen Planung ein laufender Sprint-Workflow mit Sichtbarkeit, Belastungssteuerung und Nachverfolgung wird.
Empfohlene Workflows
Diese Anwendungsfälle profitieren besonders davon, wenn Sprintplanung nicht isoliert bleibt, sondern direkt in Delivery, Abhängigkeiten und Reporting übergeht.
Mehr Ideen? Stöbere in Anwendungsfällen .
FAQ zur Sprintplanungs-Vorlage
Was sollte eine Sprintplanungs-Vorlage mindestens enthalten? +
Mindestens gehören Sprintziel, ausgewählte Arbeit, Owner, Schätzung, reale Kapazität, Abhängigkeiten, Risiken, Definition of Done und ein kurzer Nachbereitungsblock hinein. Fehlt einer dieser Punkte, verschiebt das Team Unsicherheit meist nur in die ersten Tage des Sprints.
Worin unterscheidet sich Sprintplanung von Backlog Refinement? +
Backlog Refinement klärt und schärft Arbeit vorab. Sprintplanung entscheidet dann, was mit der aktuell verfügbaren Kapazität wirklich in den nächsten Sprint passt und wie das Team den Sprint wertvoll macht. Wenn beides im selben Meeting vermischt wird, leidet meist entweder die Qualität der Vorbereitung oder die Qualität des Commitments.
Wie berechnen wir Sprintkapazität realistisch? +
Starte mit den tatsächlich verfügbaren Arbeitstagen je Person und ziehe Urlaub, Meetings, Support, Bereitschaften, feste Review-Termine und andere Pflichtlast ab. Vergleiche erst dann den verbleibenden Wert mit Scope und Historie. Realistische Kapazität ist kein Nebenwert, sondern die Grundlage eines belastbaren Commitments.
Wie gehen wir mit Abhängigkeiten und Freigaben in der Sprintplanung um? +
Behandle sie wie echte Lieferbedingungen. Jede relevante Abhängigkeit braucht einen Owner, einen Zieltermin und einen klaren Eskalationsweg. Wenn Freigaben oder Zuarbeit nur als Randnotiz auftauchen, werden sie meist genau dann kritisch, wenn das Team den Scope schon zugesagt hat.
Wer sollte an der Sprintplanung teilnehmen? +
Dabei sein sollten die Menschen, die den Sprint liefern, plus die Person, die Prioritäten und Produktziel verantwortet. Wenn externe Freigaben oder teamübergreifende Abhängigkeiten häufig den Sprint beeinflussen, sollte auch die Person erreichbar sein, die diese Zusagen direkt bestätigen oder blockierte Themen klären kann.
Wie lang sollte eine Sprintplanung dauern? +
Für viele zweiwöchige Sprints reichen 60 bis 120 Minuten, wenn der Backlog vorher sauber vorbereitet wurde. Je mehr offene Grundsatzfragen erst im Termin auftauchen, desto länger wird die Sitzung und desto unsicherer wird am Ende meist das Commitment.
Was sollte direkt nach der Sprintplanung passieren? +
Veröffentliche den finalen Plan, bestätige offene Abhängigkeiten aktiv, stelle sicher, dass alle Commitments einen Owner haben, und mache die ersten Follow-ups noch am selben Tag. Sprintplanung ist erst dann sauber abgeschlossen, wenn aus dem Meeting ein arbeitsfähiger Sprintstart geworden ist.
Kann ich die Vorlage in Excel oder Google Sheets verwenden? +
Ja. Die CSV lässt sich in Excel, Google Sheets und anderen Tabellen-Tools öffnen. Viele Teams starten dort, bevor sie dieselbe Struktur in einen laufenden Sprint-Workflow übernehmen.
Meinen Teams mit englischer Terminologie etwas anderes? +
Nein. Gemeint ist in der Regel dieselbe Grundstruktur: Sprintziel, realistischer Umfang, Kapazität, Abhängigkeiten, Risiken und klare Nachbereitung nach dem Meeting.