Hand hoch, wenn dir das bekannt vorkommt – du sitzt in einem endlosen Sprint-Planungsmeeting, gehst heraus und bist unsicher, was du eigentlich erreicht hast, und vergisst es sofort wieder, bis der Termin plötzlich erneut in deinem Kalender auftaucht? Es muss nicht so sein.
In diesem Artikel gebe ich dir einige hilfreiche Tipps, wie dein nächstes agiles Sprint-Planungsmeeting effizienter, effektiver und für das ganze Team weniger gefürchtet ablaufen kann.
Was ist ein Sprint-Planungsmeeting?
Ein Sprint-Planungsmeeting ist ein Treffen, bei dem das Scrum-Team entscheidet, welche Arbeiten im kommenden Sprint geliefert werden können und wie diese umgesetzt werden sollen. Es ist eine der fünf Scrum-Zeremonien, die Teil des Scrum-Frameworks sind.
Ein Sprint bezeichnet den Zeitraum, in dem die Arbeit beginnt und endet, und kann von einer bis zu mehreren Wochen dauern – am gebräuchlichsten sind jedoch zweiwöchige Sprints. Der Sprint-Planungsprozess soll Struktur geben, Erwartungen setzen und den Backlog für den nächsten Sprint festlegen.
Wann sollte das Sprint-Planungsmeeting stattfinden?
Am besten findet deine Sprint-Planungssitzung ein bis zwei Tage vor Beginn des nächsten Sprints statt. Hier erfährst du, warum:
- Zu nah am Start des Sprints verschwendest du einen wertvollen Arbeitstag für die Planung.
- Zu weit entfernt vom Sprintbeginn hat dein Team womöglich nicht alle nötigen Informationen für eine zielgerichtete Planung. Beispielsweise könnten die Ergebnisse des vorherigen Sprints oder die Verfügbarkeit im nächsten Sprint noch nicht klar sein.
Wie führt man ein Sprint-Planungsmeeting durch?
Hier ist eine visuelle Darstellung, wie das Sprint-Planungsmeeting ablaufen sollte:

- Vorbereitung des Sprint-Planungsmeetings
- Während des Sprint-Planungsmeetings
- Nach dem Sprint-Planungsmeeting
- Wie man ein Projektplanungsmeeting durchführt
Vorbereitung des Sprint-Planungsmeetings
Wahrscheinlich ist der wichtigste Teil eines Sprint-Planungsmeetings die Vorbereitung, bevor das Meeting überhaupt beginnt.
Backlog pflegen (auch Backlog-Refinement genannt)
Vor der Sprint-Planung stellt der Product Owner sicher, dass alle Einträge im Backlog, die für den Sprint infrage kommen könnten (Features, Funktionen, Bugs, Feedback usw.) der Definition of Ready des Teams entsprechen.
Der Product Owner prüft die Einträge im Backlog, um Abhängigkeiten zu erkennen oder zu entfernen, Testfälle zu schreiben, Akzeptanzkriterien zu listen und Beschreibungen festzulegen, sodass das Team den Kontext jedes Eintrags versteht.
Dieser Backlog befindet sich in der Regel in einer agilen Projektmanagement-Software oder Scrum-Software.
User Stories einschätzen
Der Product Owner muss zusammen mit dem Team auch sicherstellen, dass jede User Story die richtige Größe hat – also nicht zu groß und nicht zu klein ist. Wie gut das gelingt, zeigt sich meist mit steigender gemeinsamer Erfahrung des Teams.
Verpflichtung des Teams prüfen
Wirf einen Blick in den Kalender, um die Verfügbarkeit deines Teams einzuschätzen. Gibt es demnächst Feiertage? Ist dein Lead-Entwickler im Urlaub? Gehe ins Meeting mit einem Überblick darüber, wie viel Zeit die Teammitglieder im nächsten Sprint tatsächlich zur Verfügung haben.
Leistungsfähigkeit festlegen oder messen
Dies ist bei jedem Team unterschiedlich. Wenn du einen Durchschnittswert für die üblicherweise in einem Sprint erledigte Arbeit hast, benutze diesen als Maßstab bei der Planung, wie viel erledigt werden kann.
Wenn Sie dies für ein neu gegründetes Team einführen wollen, sollten Sie verfolgen, wie viele Story Points in jedem Sprint abgeschlossen und akzeptiert werden.
Bestimmen Sie Ihre Kapazität
Dies ist eine weitere Messgröße, die mit der Teamverfügbarkeit zusammenhängt. Wenn Ihr Team nicht vollständig einem Produkt zugewiesen ist – oder für andere Aufgaben abgezogen werden könnte – sollten Sie dies bei der Sprint-Planung berücksichtigen. Sie können zudem ein Ressourcenmanagement-, Projektplanungs- oder Projektterminierungs-Tool nutzen, um herauszufinden, wie viel Zeit jedem Teammitglied realistisch für den Sprint zur Verfügung steht.
Erstellen Sie eine Agenda für das Sprint-Planungsmeeting
Erstellen Sie eine Agenda und verteilen Sie sie an Ihr Team (Details dazu finden Sie unten). Vergessen Sie nicht, die Diskussionen und das Feedback aus Ihrem Sprint-Review und/oder Sprint-Retrospektive zu berücksichtigen.
Stellen Sie bei der Vorbereitung der Agenda außerdem sicher, dass Sie sich um die notwendigen logistischen Aspekte des Treffens gekümmert haben, einschließlich:
- Buchen der Besprechungsräume
- Bereitstellung von benötigten Materialien
- Das Team vorab darüber informieren, dass das Meeting stattfindet
- Überprüfen der Videokonferenz- und sonstigen Verbindungsmöglichkeiten.
Die Zeitbegrenzung für das Meeting hängt von der Dauer der Sprints des Teams ab. Wenn Sie zweiwöchige Sprints verwenden, sollte die Sprint-Planung nicht länger als zwei bis vier Stunden dauern (obwohl meiner Erfahrung nach 60–90 Minuten meist ausreichend sind).
Während des Sprint-Planungsmeetings
Wir haben eine großartige Agenda für Sprint-Planungsmeetings für den Sprint-Planungsprozess entwickelt. Ich werde gleich noch genauer auf die Agenda eingehen, um Ihnen die einzelnen Schritte näher zu bringen:
Check-in mit dem Team
Unterschätzen Sie nicht die Bedeutung von Smalltalk, um die Stimmung aufzulockern und das Team zu aktivieren – insbesondere in virtuellen Umgebungen. Sie könnten sogar in Erwägung ziehen, mit einer klassischen Icebreaker-Frage zu beginnen, um den kreativen Fluss anzuregen.
Bevorstehende Prioritäten überprüfen
Wenn das Team eingestimmt ist, öffnen Sie das Product Backlog und besprechen Sie die anstehenden Themen einzeln. Das Team muss zu jedem Eintrag im Backlog diskutieren und nachfragen. Der Product Owner ist verantwortlich dafür, die Details hinter jedem Eintrag im Backlog zu klären.
Prioritäten schätzen
Wenn Aufgaben noch nicht geschätzt wurden, schätzen Sie diese, um ein Gefühl dafür zu bekommen, wie viele für einen Sprint ausgewählt werden können. Sie könnten für diesen Prozess Planning Poker verwenden.
Roadmap-Fortschritt überprüfen
Es ist wahrscheinlich, dass der Scrum Master, der Product Owner oder ein anderes Teammitglied seit der letzten Sprintplanung Neuigkeiten von externen Stakeholdern erhalten hat. Es ist wichtig, alle neuen Erkenntnisse zu überprüfen, die Einfluss auf die Roadmap nehmen, damit das Team den Kontext für den kommenden Sprint kennt.
Prognostizierte Geschwindigkeit überprüfen
Sprechen Sie Urlaube, Feiertage und konkurrierende Projekte an – das ist ein wichtiger Schritt, um sicherzustellen, dass sich das Team nicht überschätzt, was die verfügbare Zeit angeht. Danach sollte das Team mit seiner Velocity vertraut sein, um gezielt User Stories für den nächsten Sprint auszuwählen. Es ist immer hilfreicher, sich an einem konkreten Velocity-Wert zu orientieren, als sich nur auf das Bauchgefühl zu verlassen.
Sprint-Backlog-Themen auswählen
Beginnen Sie oben im Backlog und wählen Sie in gemeinsamer Arbeit die Themen, die in diesem Sprint bearbeitet werden sollen. Lassen Sie das Team jede Aufgabe prüfen, um festzulegen, wer welche übernimmt.
Ziel ist es, das Meeting so zu verlassen, dass klar ist, woran jede Person arbeitet, wie sie die Aufgabe löst und was die Definition von "fertig" für jedes Thema ist (also wie Sie erkennen, dass die Aufgabe erledigt ist).
Sprint-Ziel definieren
Nachdem Sie die Themen für den Sprint ausgewählt haben, stellen Sie sicher, dass diese mit dem angestrebten Ergebnis für den Sprint übereinstimmen. Nehmen Sie ggf. Anpassungen am Sprint-Backlog vor.
Ausrichtung bestätigen
Der Scrum Master überprüft den vorgeschlagenen Plan hinsichtlich Team-Velocity, Kapazitäten und auf Übereinstimmung mit der Produktvision. Am wichtigsten ist, dass der Scrum Master sicherstellt, dass das Team dem Plan zustimmt. Das bedeutet, dass jede Person gefragt wird, ob sie damit einverstanden ist.
Idealerweise sind alle auf einer Linie und zuversichtlich, dass sie das Arbeitspaket basierend auf dem heutigen Stand liefern können. Veränderungen wird es immer geben – aber wenn das Team sich sicher fühlt, das Sprint-Ziel zu erreichen, ist Ihre Arbeit vorerst getan.
Nach dem Sprint-Planning-Meeting
Lassen Sie das Team arbeiten! Jeder sollte nach dem Sprint-Planning-Meeting genug zu tun haben. Das Team wird vielleicht darauf brennen, in die Details einzutauchen oder gemeinsam an einigen User Stories zu arbeiten. Sie können morgen beim täglichen Standup (auch als Daily Scrum Meeting bekannt) einchecken und sich austauschen.
Wer ist an dem Sprint-Planning-Meeting beteiligt?
Der Scrum Master, Product Owner und das Entwicklungsteam sind an den Sprint-Planning-Meetings beteiligt.

Der Scrum Master
Der Scrum Master moderiert das Sprint-Planning-Meeting und sorgt dafür, dass Besprechungsräume gebucht, Materialien bereitgestellt und alle Beteiligten vorbereitet sind.
Der Scrum Master sollte das Meeting zeitlich begrenzen, abhängig von der Dauer des Sprints. Wenn das Team beispielsweise in zweiwöchigen Sprints arbeitet, sollte das Sprint-Planning-Meeting nicht länger als 2-4 Stunden dauern (kürzer ist bevorzugt, falls möglich!).
Der Scrum Master muss die Zeit sinnvoll einteilen, damit das Team sich auf das Sprint-Ziel einigt, bevor das Meeting beendet wird.
Der Product Owner
Der Product Owner ist dafür verantwortlich, das Backlog vor dem Sprint-Planning-Meeting vorzubereiten. Er oder sie muss die Details zu jedem Backlog Item klären und Fragen zu Anwendungsfällen und/oder Akzeptanzkriterien beantworten können.
Das Entwicklungsteam
Designer, Entwickler, Testingenieure—alle, die zum Arbeitsergebnis beitragen—müssen aktiv teilnehmen. Nach dem Sprint-Planning-Meeting sollten sie genau wissen, was von ihnen erwartet wird und welche Aufgaben im nächsten Sprint Priorität haben.
Beachten Sie, dass Teams mit der Zeit besser im Sprint-Planning werden. Ist das Team neu gebildet oder neu im agilen Projektmanagement, schätzt es anfangs noch unsicher ein, wie viel in einem Sprint tatsächlich geschafft werden kann. Mit wachsender Erfahrung im agilen Arbeiten werden die Prognosen immer zuverlässiger.
Warum sollte man ein Sprint-Planning-Meeting durchführen?
Sie sollten Sprint-Planning-Meetings durchführen, damit Teams verstehen, woran sie arbeiten sollen und – noch wichtiger – warum.
Wenn das gesamte Team in diese Meetings eingebunden wird, fördert das die Zusammenarbeit – das Team wird effizienter und fühlt sich sicherer darin, was es liefern soll.
Im Folgenden spreche ich über einige der größten Vorteile von Sprint-Planning-Meetings.
- Ziele besser definieren
- Team-Alignment und Commitment fördern
- Bezugsrahmen für die Messung der Velocity schaffen

1. Ziele besser definieren
Wenn Sie als Scrum Master in einem Team arbeiten, das Entwicklungsarbeit leistet und agile Methoden nutzt, sollten Sie ein Sprint-Planning-Meeting durchführen.
Ein erfolgreiches Sprint-Planning-Meeting bereitet Ihr Team auf den Erfolg vor, denn alle verstehen genau, welches Ziel für den jeweiligen Sprint gesetzt wurde.
Im Sprint-Planning werden zwei Hauptaspekte definiert: das Sprint-Ziel und das Sprint-Backlog.
Sprint-Ziel
Ein Sprint-Ziel ist eine kurze (ein bis zwei Sätze) Beschreibung dessen, was das Team im Laufe des Sprints abschließen möchte. Es wird gemeinsam formuliert und veröffentlicht, sodass jederzeit darauf Bezug genommen werden kann.
Das Sprint-Ziel ist eine schnelle und leicht verständliche Aussage für Stakeholder, was das Team im aktuellen Sprint bearbeitet, ohne dass sie ins Detail des Backlogs einsteigen müssen.
Ein Beispiel für ein Sprint-Ziel könnte sein: Feature X zur Einführung an den Feiertagen entwickeln (was signalisiert, dass die Auslieferung bis zu einem bestimmten Meilenstein das Hauptziel des Sprints ist).
Sprint-Backlog
Das Sprint-Backlog ist eine Liste von Produkt-Backlog-Elementen, die das Team auswählt und sich verpflichtet, während des Sprints daran zu arbeiten. Es enthält außerdem die notwendigen Aufgaben, die zur Lieferung der Arbeit erforderlich sind, sowie eine Schätzung, wie lange jede Aufgabe dauern sollte.
2. Förderung der Team-Ausrichtung und Akzeptanz
Sprint-Planungsmeetings erfordern eine kooperative Teamarbeit, um die gewünschten Ergebnisse zu erzielen. Das Team – und nicht ein übermächtiger Product Owner oder ein externer Stakeholder – entscheidet darüber, wie viel während eines Sprints umgesetzt wird.
Auch Ihre Teammitglieder gewinnen ein Gefühl der Selbstbestimmung, indem sie ihren eigenen Arbeitsfluss steuern. Sie profitieren von einer besseren Abstimmung mit anderen, da sie Zeit haben, zu besprechen, wie ihre Arbeit im neuen Sprint zusammenpasst.
3. Einen Bezugspunkt zur Messung der Velocity schaffen
Die Sprint-Velocity ist eine Metrik, die angibt, wie viel Arbeit ein Team in einem einzelnen Sprint bewältigen kann. Nachdem ein Team eine Zeit lang zusammengearbeitet hat, kann man die durchschnittliche Velocity berechnen, indem man die abgeschlossenen Story-Punkte am Ende jedes Sprints zusammenzählt.
Wenn zum Beispiel im Sprint 1 das Team 25 Story-Punkte erreicht hat, im Sprint 2 35 und im Sprint 3 30, beträgt die Team-Velocity 30.
25 + 35 + 30 = 90/3 = 30
Künftig weiß das gesamte Scrum-Team, dass es durchschnittlich 30 Story-Punkte pro Sprint abschließt und kann diesen Wert als Orientierung nutzen, wenn es im Sprint Planning die Backlog-Elemente betrachtet.
Die Velocity wird im Zeitverlauf schwanken, aber eine erfahrene agile Einheit wird ihre Velocity tendenziell steigern, je eingespielter sie ist und je sicherer sie im Umgang mit dem Produkt wird. Der Product Owner sollte die Velocity berücksichtigen, wenn er/sie abschätzt, wie viele Sprints für die Veröffentlichung der nächsten Produktversion benötigt werden.
Sprint-Planungsmeeting-Agenda [Download]

Hier können Sie sich die Vorlage holen (Mitgliedschaft erforderlich) und mit den Erkenntnissen aus diesem Artikel ausfüllen, um die Checkliste für Ihr nächstes Sprint-Planning bereit zu machen.
Außerdem erhalten Sie eine praktische Sprint-Planning-Checkliste, die Ihnen bei der Vorbereitung des Meetings hilft (egal, welche Rolle Sie haben), sowie eine E-Mail-Vorlage, die Sie an Stakeholder und andere Eingeladene senden können.
Wie geht es weiter?
Sie suchen weitere Tipps, wie Sie ein Sprint-Planungsmeeting durchführen? Oder möchten Sie Ihre eigenen Erfahrungen teilen? Diskutieren Sie mit hunderten anderen Digital Project Managern im Slack mit einer DPM-Mitgliedschaft!
