Sprint-Planung: So führen Sie ein Meeting durch, das den Sprint übersteht

Es gibt einen Grund, warum Wettervorhersagen eine Regenwahrscheinlichkeit von 70 % angeben, anstatt zu versprechen, dass es genau um 15 Uhr regnen wird. Sie nutzen die verfügbaren Informationen, berücksichtigen Unsicherheiten und aktualisieren ihre Vorhersagen, sobald neue Daten vorliegen. Sie können Ihren Nachmittag dennoch entsprechend planen, solange Sie die Vorhersage nicht mit einer Garantie verwechseln.

Die Sprintplanung funktioniert nach einem ähnlichen Prinzip. Ein Scrum-Team verfügt über ein Product Backlog, eine Einschätzung seiner verfügbaren Kapazität und ein Ziel, das es erreichen möchte. Doch manche Details der Arbeit werden erst im Laufe des Sprints deutlich. Eine Planung, die jede Stunde im Voraus erfolgt, lässt wenig Raum für solche Erkenntnisse, während es ohne eine gemeinsame Ausrichtung schwieriger ist, zu entscheiden, was Aufmerksamkeit verdient.

Das Ziel besteht darin, sich auf ein wertvolles Ergebnis zu einigen und abzuschätzen, wie viel Arbeit das Team abschließen kann, um dieses zu erreichen. Auf dieser Grundlage kann das Team seinen Plan anpassen, sobald es weitere Informationen hat, ohne dabei das Ziel des Sprints aus den Augen zu verlieren.

Dieser Leitfaden behandelt die Vorbereitung des Backlogs, eine zeitlich festgelegte Planungsagenda, praktische Berechnungen der Kapazität sowie ein Beispiel, das zeigt, wie der Plan während des Sprints angepasst werden kann.

Was ist die Sprint-Planung?

Die Sprintplanung ist ein Scrum-Event, das zu Beginn jedes Sprints stattfindet, um zu vereinbaren, was das Team erreichen möchte und wie es die Arbeit angehen wird. Dabei kommt das gesamte Scrum-Team zusammen, einschließlich des Product Owners, des Scrum Masters und der Entwickler. Andere Spezialisten, wie beispielsweise Sicherheitsingenieure oder Kundenbetreuer, können ebenfalls teilnehmen, wenn ihre Beiträge dem Team helfen, fundierte Entscheidungen zu treffen.

Laut dem Scrum Guide sollte jede Planungssitzung drei Ergebnisse liefern: ein Sprintziel, das den Wert der Arbeit verdeutlicht, eine Auswahl von Product-Backlog-Elementen, die dieses Ziel unterstützen, sowie einen ersten Plan für deren Umsetzung. Zusammen bilden diese das Sprint-Backlog, das die Entwickler im Laufe des Sprints kontinuierlich aktualisieren.

Der Scrum Guide sieht für einen einmonatigen Sprint maximal acht Stunden vor, und kürzere Sprints benötigen in der Regel weniger Zeit. Mit einem gut aufbereiteten Backlog lässt sich die unten stehende Tagesordnung in zwei Stunden unterbringen.

Falls Ihnen einige dieser Begriffe unbekannt sind: In unserem Glossar finden Sie die Grundlagen zu Agilität und Scrum.

Die drei Fragen, die die Sprint-Planung beantworten

Jede Sprint-Planungssitzung dreht sich um drei Fragen:

Der Scrum Guide strukturiert die Planung anhand dieser Fragen, ausgehend vom Wert, den Sie liefern möchten. Sobald dies allen klar ist, lässt sich leichter entscheiden, welche Backlog-Elemente Beachtung verdienen und wie viel Arbeit Ihr Team realistischerweise übernehmen kann.

Warum der Sprint wichtig ist

Das Sprint-Ziel gibt dem Team eine Zielvorstellung und hilft den Stakeholdern zu verstehen, was sie erwarten können. Einigen Sie sich mit Ihrem Scrum-Team auf dieses Ziel, bevor die Planungssitzung endet.

Beschreiben Sie ein Ergebnis, das für alle erkennbar ist, wie beispielsweise „Testnutzer können Teamkollegen einladen“, anstatt ein Einzelziel wie „34 Story-Punkte abschließen“. Wenn ein unerwartetes Problem auftritt, hilft das Ziel dem Team bei der Entscheidung, welche Aufgaben angepasst werden müssen, um das beabsichtigte Ergebnis dennoch zu erreichen.

Was das Team in diesem Sprint fertigstellen kann

Sobald Sie sich auf das Ziel geeinigt haben, ist es an der Zeit, herauszufinden, was das Team realistisch liefern kann.

Die Entwickler wählen Backlog-Elemente in Absprache mit dem Product Owner aus und berücksichtigen dabei die verfügbare Kapazität, die bisherige Leistung sowie die „Definition of Done“. Dies ist auch der richtige Zeitpunkt, um bestehende Verpflichtungen zu überprüfen, die sich darauf auswirken könnten, wie viel Zeit dem Team für die Sprint-Arbeit zur Verfügung steht.

Viele Teams nutzen Story-Punkte, um den relativen Aufwand und die Komplexität von Backlog-Elementen zu vergleichen. Eine Fibonacci-Skala kann dabei helfen, diese Diskussionen zu strukturieren, insbesondere wenn der damit verbundene Aufwand unklar ist.

Wie das Team die Arbeit erledigen wird

Nachdem die Backlog-Elemente ausgewählt wurden, erarbeiten die Entwickler, wie sie diese in ein fertiges Produktinkrement umsetzen, das der Definition of Done entspricht. Der Scrum Guide empfiehlt, größere Elemente in kleinere Arbeitspakete aufzuteilen, deren Größe oft so bemessen ist, dass sie einen Tag oder weniger in Anspruch nehmen.

Das bedeutet nicht, dass Sie jede Stunde des Sprints genau festlegen müssen. Für die ersten Tage ist möglicherweise ein detaillierterer Plan erforderlich, während spätere Aufgaben offen für Anpassungen bleiben können, sobald neue Details bekannt werden. Wenn frühe Schätzungen als feste Verpflichtungen behandelt werden, kann dies das Team unter Druck setzen, die ursprünglichen Zahlen einzuhalten, selbst wenn sich der Umfang im Laufe des Sprints ändert.

Wie Dave West, CEO von Scrum.org, erklärt:

Eine Prognose, die dazu dient, einen Termin zu rechtfertigen, führt genau zu jenem Verhalten, das das Vertrauen untergräbt – wie das Aufblähen von Schätzungen, das Verschleiern von Risiken oder das heimliche Neudefinieren des Begriffs „erledigt“, um eine bestimmte Nummer zu erreichen.

Was ist der Unterschied zwischen Sprint-Planung und Backlog-Verfeinerung?

Die Backlog-Verfeinerung verschafft Ihrem Team ein klareres Verständnis der anstehenden Arbeit, bevor entschieden wird, was in den nächsten Sprint aufgenommen wird. Die Sprintplanung baut auf dieser Vorbereitung auf, um sich auf ein Ziel zu einigen, Backlog-Elemente auszuwählen und einen ersten Plan festzulegen.

Die beiden Aktivitäten dienen innerhalb von Scrum unterschiedlichen Zwecken:

Halten Sie genügend anstehende Backlog-Elemente so detailliert bereit, dass das Team bei der Planung des Sprints klare Auswahlmöglichkeiten hat. Wie viel Vorbereitung sinnvoll ist, hängt davon ab, wie schnell sich Prioritäten ändern und wie viel Unsicherheit noch besteht. Elemente, die weiter unten im Backlog stehen, können weniger detailliert bleiben, bis sie näher an die Auswahl rücken.

So bereiten Sie sich auf die Planung des Sprints vor

Überprüfen Sie einige Tage im Voraus, ob das Backlog in der richtigen Form ist und alle über die Informationen verfügen, die sie für ihre Entscheidungen benötigen. So können Sie die Sitzung darauf verwenden, zu besprechen, was geliefert werden soll und wie Sie dabei vorgehen wollen, ohne jede Anforderung von Grund auf neu klären zu müssen.

Hier ist eine Checkliste, die Sie vor Ihrem nächsten Sprint durchgehen sollten:

Wenn Sie die Sprint-Retrospektive und die Planungssitzung zeitlich dicht beieinander ansetzen, planen Sie genügend Zeit ein, damit in beiden Sitzungen eine gründliche Diskussion stattfinden kann. Die Erkenntnisse aus der Retrospektive sollten in den Plan des nächsten Sprints einfließen; achten Sie daher darauf, dass keines der beiden Meetings gehetzt wirkt.

Agenda für die Sprint-Planung: Ein zeitlich gegliedertes Beispiel für einen zweiwöchigen Sprint

Beginnen Sie bei einem zweiwöchigen Sprint mit einer zweistündigen Planungssitzung, insbesondere wenn das Backlog bereits verfeinert wurde. Planen Sie zusätzliche Zeit ein, wenn die Arbeit komplexe Abhängigkeiten beinhaltet oder mehrere Entscheidungen erfordert, die besprochen werden müssen.

Sie können diese Beispiel-Tagesordnung an die Bedürfnisse Ihres Teams anpassen.

Bevor Sie zum Abschluss kommen, können Sie eine kurze Zuversichtsprüfung wie Fist of Five durchführen, bei der jeder seine Zuversicht im Plan mit null bis fünf Fingern bewertet. Wenn jemand eine niedrige Bewertung abgibt, fragen Sie nach den Gründen für die Bedenken. Dies könnte eine ungelöste Abhängigkeit, eine zu ehrgeizige Prognose oder eine Anforderung aufdecken, die weiterer Diskussion bedarf.

Das Ziel ist es, Bedenken anzusprechen, solange noch Zeit bleibt, den Plan anzupassen.

So führen Sie die Sprint-Planung in 6 Schritten durch

Sobald Sie das Backlog vorbereitet und die Teilnehmer bestätigt haben, beginnen Sie mit der Planungssitzung. Das Ziel dabei ist es, dem Team dabei zu helfen, seine Prioritäten und die verfügbare Kapazität in einen Plan umzusetzen, von dem es überzeugt ist, dass es ihn umsetzen kann.

Schritt 1: Überprüfen Sie die bisherigen Arbeiten und einigen Sie sich auf ein Ziel für den Sprint

Beginnen Sie mit einem kurzen Überblick darüber, was fertiggestellt wurde, was noch offen ist und ob Maßnahmen aus der Retrospektive den nächsten Sprint beeinflussen sollten. Konzentrieren Sie sich dabei auf alles, was die Prioritäten oder die Vorgehensweise des Teams verändern könnte, anstatt die gesamte Sprint-Review noch einmal durchzugehen.

Lassen Sie anschließend den Product Owner das vorgeschlagene Sprint-Ziel vorstellen und erläutern, wie es das übergeordnete Produktziel unterstützt. Geben Sie den Entwicklern Raum, den Umfang zu hinterfragen, Abhängigkeiten anzusprechen und Anpassungen vorzuschlagen.

Wenn das Ziel beispielsweise darin besteht, dass Kunden den Bestellvorgang abschließen können, ohne den Vertrieb zu kontaktieren, einigen Sie sich darauf, wie ein erfolgreicher Bestellvorgang aussieht. Umfasst dies die Bestätigung der Zahlung und die Fehlerbehandlung? Ist die automatische Zustellung der Quittung für die erste Version unerlässlich?

Diese Diskussionen helfen Ihnen dabei, ein Ergebnis zu definieren, auf das das Team hinarbeiten kann. Der Wortlaut kann sich im Zuge der Auswahl der Backlog-Elemente noch ändern, aber alle sollten sich vor Ende der Planung auf das endgültige Ziel einigen.

Schritt 2: Berechnen Sie die verfügbare Kapazität des Teams

Bevor Sie die Arbeit auswählen, sollten Sie festlegen, wie viel Zeit Ihre Entwickler realistisch gesehen für den Sprint aufwenden können.

Beginnen Sie mit der Anzahl der Arbeitstage und der voraussichtlichen Verfügbarkeit jeder Person. Berücksichtigen Sie dann geplanten Urlaub, Scrum-Ereignisse, Support-Aufgaben und andere bekannte Verpflichtungen. Wenn ein Entwickler die Hälfte seiner Woche damit verbringt, Probleme in der Produktion zu beheben, sind diese Stunden bereits gebunden und stehen für den geplanten Sprint nicht zur Verfügung.

Eine einfache Berechnung lautet: Verfügbare Kapazität = Gesamtarbeitszeit − Bekannte Verpflichtungen

Beispielsweise könnte ein Entwickler mit 80 Arbeitsstunden über zwei Wochen 8 Stunden Urlaub, 10 Stunden Meetings und 12 Stunden Support-Einsatz haben. Damit bleiben 50 Stunden, bevor zusätzliche Unwägbarkeiten berücksichtigt werden müssen.

Vergleichen Sie diese Zahl mit der bisherigen Leistung des Teams. Die Velocity gibt an, wie viel Arbeit das Team in früheren Sprints abgeschlossen hat, während die Kapazität die für diesen Sprint verfügbare Zeit widerspiegelt.

Schritt 3: Überprüfen Sie die noch nicht abgeschlossenen Arbeiten aus dem vorherigen Sprint

Unfertige Backlog-Elemente sollten noch einmal überprüft werden, bevor Sie sie in den neuen Sprint aufnehmen. Ein Element, das vor zwei Wochen noch wichtig war, hat möglicherweise an Priorität verloren, oder das Team hat etwas gelernt, das sich auf den verbleibenden Arbeitsaufwand auswirkt.

Gehen Sie jedes Element gemeinsam mit dem Product Owner durch und berücksichtigen Sie dabei Folgendes:

Bei Aufgaben, die noch in den Sprint gehören, nutzen Sie den verbleibenden Aufwand, um abzuschätzen, wie viel Kapazität dafür benötigt wird. Ein halbfertiges Element erfordert möglicherweise weniger Arbeit als ursprünglich veranschlagt, gilt aber dennoch als unvollendet, bis es die „Definition of Done“ erfüllt.

Schritt 4: Wählen Sie Backlog-Elemente aus, die das Ziel unterstützen

Wenn Ihre Kapazität und die noch ausstehenden Aufgaben bekannt sind, können Entwickler die Product-Backlog-Elemente auswählen, von denen sie glauben, dass sie diese abschließen können.

Beginnen Sie mit Elementen, die das Sprint-Ziel direkt unterstützen. Besprechen Sie deren Akzeptanzkriterien, technische Abhängigkeiten und etwaige Unsicherheiten, die die Umsetzung beeinträchtigen könnten. Wenn ein Element zu umfangreich oder unklar ist, sollten Sie erwägen, es in kleinere Teile aufzuteilen, die innerhalb des Sprints einen Wert liefern können.

Möglicherweise haben Sie auch Spielraum für Wartungsarbeiten oder andere Prioritäten für Produkte, aber prüfen Sie, ob die Übernahme dieser Arbeiten das Hauptziel gefährden könnte.

Wie viel Kapazität sollten Sie reservieren?

Die Planung von nur 80 % der verfügbaren Kapazität kann ein sinnvoller Ausgangspunkt für Teams sein, die regelmäßig unerwartete Support-Aufgaben bewältigen müssen, doch Scrum schreibt keinen festen Prozentsatz vor.

Wenn Ihr Team häufig Unterbrechungen erlebt hat, könnten Sie 10–20 % seiner angepassten Kapazität reservieren und diesen Spielraum mit dem Bedarf aus früheren Sprints vergleichen. Ein Team mit stabilem Arbeitsaufkommen und wenigen Unterbrechungen benötigt möglicherweise weniger. Ein Team, das einen Live-Dienst mit häufigen Incidents betreut, benötigt möglicherweise mehr.

Vermeiden Sie es, dieselbe Verpflichtung doppelt zu zählen. Wenn geplante Supportstunden bereits in Schritt 2 abgezogen wurden, sollte der zusätzliche Puffer Unsicherheiten abdecken, die über diese bekannte Workload hinausgehen. Nutzen Sie die daraus resultierende Kapazität als Orientierungshilfe für die Diskussion, nicht als Ziel, das es zu erreichen gilt.

Schritt 5: Gliedern Sie die Arbeit auf und prüfen Sie die Abhängigkeiten

Sobald Sie die Backlog-Elemente ausgewählt haben, können die Entwickler erarbeiten, wie sie diese umsetzen werden. Dazu kann es gehören, größere Elemente in Entwicklungs-, Test-, Integrations- und Überprüfungsaufgaben aufzuteilen.

Achten Sie genau auf die Reihenfolge der Arbeitsschritte. Wenn die Checkout-Oberfläche von der Integration eines Zahlungsanbieters abhängt, sollte das Team wissen, wann diese Integration bereitstehen muss. Wenn ein anderes Team eine Änderung der Sicherheit genehmigen muss, klären Sie, wie und wann diese Entscheidung getroffen wird.

Planen Sie die anstehenden Aufgaben detaillierter und lassen Sie spätere Aufgaben für weitere Diskussionen offen. Der Scrum Guide empfiehlt, die ausgewählten Aufgaben in kleinere Elemente zu unterteilen, die in der Regel eine Größe von einem Tag oder weniger haben, doch die Entwickler entscheiden selbst, wie sie die Arbeit organisieren und verteilen.

Stellen Sie sicher, dass der Plan die „Definition of Done“ berücksichtigt, einschließlich der erforderlichen Test- und Integrationsarbeiten. Sollte eine Abhängigkeit die Auslieferung verhindern könnten, überprüfen Sie die ausgewählten Elemente oder passen Sie den Auslieferungsansatz an, bevor Sie den Plan abschließen.

Schritt 6: Das Sprint-Backlog fertigstellen und freigeben

Halten Sie das Sprint-Ziel, die ausgewählten Product-Backlog-Elemente und den vorläufigen Lieferplan an einem Ort fest, auf den das Team zugreifen und den es aktualisieren kann. Zusammen sollten diese Angaben deutlich machen, was das Team erreichen möchte und welche Aufgaben als Nächstes in Angriff genommen werden müssen.

Vergewissern Sie sich vor Abschluss des Meetings, dass Einigkeit über das Ziel herrscht, und geben Sie allen die Gelegenheit, noch offene Bedenken hinsichtlich der Prognosen anzusprechen. Sollte ein wichtiges Problem der Abhängigkeit oder der Kapazität ungelöst bleiben, besprechen Sie, was geändert werden muss, bevor das Team mit der Arbeit beginnt.

Während des Sprints bietet das Daily Scrum den Entwicklern die Möglichkeit, den Fortschritt in Richtung des Ziels zu überprüfen und das Sprint-Backlog anzupassen. Ein Burndown- oder Burnup-Diagramm kann dabei helfen, Veränderungen im Fortschritt zu veranschaulichen, während die zugrunde liegenden Aufgaben Details liefern. Wenn neue Informationen den ausgewählten Umfang beeinflussen, können Entwickler Anpassungen mit dem Product Owner besprechen, ohne das Sprint-Ziel zu gefährden.

Beispiel für eine Sprint-Planung: Ein Team mit 6 Entwicklern

Schauen wir uns einmal an, wie diese Entscheidungen in der Praxis funktionieren.

Stellen Sie sich vor, Sie planen einen zweiwöchigen Sprint für ein B2B-Abrechnungsprodukt. Ihr Team besteht aus sechs Entwicklern und hat folgendes Ziel vorgeschlagen: „Neue Kunden können beim Bezahlvorgang mit Karte bezahlen, ohne den Vertrieb kontaktieren zu müssen.“

Bevor Sie Backlog-Elemente auswählen, müssen Sie wissen, wie viel Zeit dem Team zur Verfügung steht. Nehmen Sie für dieses Beispiel an, dass jeder Entwickler täglich sechs Stunden für konzentrierte Arbeit an einem Projekt zur Verfügung hat, bevor geplante Scrum-Ereignisse und andere Verpflichtungen abgezogen werden.

So funktioniert die Berechnung der Kapazität über 10 Arbeitstage hinweg:

Sie haben nun 216 Stunden für die geplante Arbeit zur Verfügung, nachdem Sie einen exemplarischen Puffer von 20 % einkalkuliert haben. In der Praxis würden Sie diese Reserve danach bemessen, inwieweit ungeplante Arbeiten frühere Sprints unterbrochen haben.

Wählen Sie die Arbeiten aus, die das Sprint-Ziel unterstützen

Nachdem die Kapazität festgelegt wurde, prüfen die Entwickler gemeinsam mit dem Product Owner die Backlog-Elemente, die mit dem Checkout zusammenhängen.

Hier ist eine anschauliche Auswahl auf der Grundlage der anfänglichen Schätzungen des Aufwands für Aufgaben:

Diese Schätzungen lassen 6 Stunden innerhalb des geplanten Arbeitsaufwands sowie den 54-Stunden-Puffer für unerwartete Aufgaben übrig. Das Team hat außerdem eine Verbesserung des Dashboards für die Berichterstellung im Product Backlog. Obwohl diese wertvoll ist, trägt sie nicht direkt zum Checkout-Ziel bei. Der Product Owner und die Entwickler vereinbaren, sie für einen zukünftigen Sprint zurückzustellen.

Passen Sie den Plan an, wenn sich etwas ändert.

Am sechsten Tag führt der Anbieter eine API-Änderung ein, die einen Teil der Integration beeinträchtigt. Die Entwickler untersuchen den Sachverhalt und schätzen die zusätzliche Arbeit ein.

Anstatt die ursprüngliche Aufgabenliste fortzuführen, besprechen sie die Auswirkungen mit dem Product Owner. Wenn die Korrektur in die verbleibende Kapazität passt, können sie ihr Priorität einräumen und optionale Anpassungen am Design der Quittung oder eine andere Aufgabe mit niedrigerer Priorität zurückstellen. Die Zahlungsbestätigung und andere wesentliche Arbeiten müssen weiterhin der „Definition of Done“ entsprechen.

Sollte der Korrekturaufwand größer ausfallen als erwartet, muss der verbleibende Umfang neu bewertet und geprüft werden, ob das Ziel des Sprints noch erreichbar ist.

Möglicherweise hat das Team am Ende weniger Backlog-Elemente fertiggestellt als ursprünglich prognostiziert. Wenn die Kunden jedoch den Bestellvorgang wie vorgesehen abschließen können und die Arbeit der „Definition of Done“ entspricht, ist das Sprint-Ziel erreicht.

Beispiele für Sprint-Ziele für andere Teams

Sie können denselben Planungsansatz auch auf die Arbeit außerhalb der Softwareentwicklung anwenden, obwohl Scrum selbst ein spezifisches Framework mit festgelegten Verantwortlichkeiten und Ereignissen ist.

Ein Marketingteam könnte sich beispielsweise das Ziel setzen: „Die Landingpage für das Webinar veröffentlichen und Besuchern die Anmeldung ohne manuelle Unterstützung ermöglichen.“ Ein Betriebsteam könnte sich zum Ziel setzen: „Sicherstellen, dass jeder Mitarbeiter der nächsten Onboarding-Gruppe am ersten Arbeitstag über die erforderliche Ausrüstung und den notwendigen Systemzugang verfügt.“

Beide Ziele beschreiben Ergebnisse, die die Entscheidungen des Teams während des gesamten Sprints leiten können. Die Backlog-Elemente und die Lieferpläne werden sich unterscheiden, aber das Team muss dennoch seine Kapazität berücksichtigen und sich darauf einigen, wie Erfolg aussieht.

Häufige Fehler bei der Planung des Sprints und wie man sie behebt

Bei der Sprint-Planung kann es zu Problemen kommen, wenn Teams Story-Punkte zur Beurteilung der individuellen Leistung heranziehen, unklare Backlog-Elemente in das Meeting einbringen, Arbeit zu starr zuweisen oder Testanforderungen und externe Abhängigkeiten übersehen.

Mit ein paar Anpassungen können Sie diese Probleme erkennen, bevor sie sich auf die Umsetzung auswirken.

Wenn dieselben Probleme über mehrere Sprints hinweg immer wieder auftreten, bringen Sie sie in die Sprint-Retrospektive ein und einigen Sie sich auf eine Änderung, die Sie im nächsten Sprint testen können. Diese Vorlagen für die Sprint-Retrospektive können Ihnen dabei helfen, Beobachtungen und Folgeaktionen festzuhalten.

Nutzen Sie am Ende des Sprints das Sprint-Review-Meeting, um das fertiggestellte Inkrement gemeinsam mit den Stakeholdern zu prüfen und zu besprechen, welche Aufgaben das Team als Nächstes in Angriff nehmen soll.

So führen Sie eine Sprint-Planung in ClickUp durch

Die Sprint-Planung erfordert mehr Aufwand, wenn Aufgaben, Schätzungen der Kapazität und Planungsentscheidungen auf verschiedene Tools verteilt sind. ClickUp führt diese Informationen zusammen, sodass das Team die Arbeit im Zusammenhang mit der Kapazität überprüfen und Planungsentscheidungen überdenken kann, wenn sich der Plan ändert.

Beginnen Sie mit der ClickUp-Vorlage für die agile Sprint-Planung. Die Ansichten „Backlog“, „Status der Entwicklung“ und „Ressourcen“ helfen Ihnen dabei, anstehende Arbeiten zu überprüfen und sich auf die Planungsbesprechung vorzubereiten.

Kostenlose Vorlage herunterladen

So gehen Sie bei den wichtigsten Entscheidungen vor:

Fragen Sie Brain² vor der nächsten Planungssitzung: „Welche ungelösten Abhängigkeiten sind bei unserer letzten Sprint-Planungssitzung aufgetreten?“ Brain kann den Kontext aus den erfassten Meeting-Notizen abrufen. Vergleichen Sie diese Details mit den aktuellen Aufgaben, bevor Sie sie als Grundlage für die nächste Prognose verwenden.

Preise für ClickUp

Wie viel sollten Sie vor Beginn eines Sprints planen?

Eine Sprint-Planungssitzung sollte dem Team genügend Klarheit verschaffen, um mit der Arbeit beginnen zu können.

Die oben genannte zeitlich festgelegte Tagesordnung und das Beispiel für die Kapazität dienen als Ausgangspunkt. Passen Sie diese an die Workload des Teams an und vergleichen Sie anschließend die Prognose mit der fertiggestellten Arbeit und den Unterbrechungen, um die nächste Planung zu verbessern.

In ClickUp können Sie Planungsnotizen mit Sprint-Aufgaben verknüpfen und das Sprint-Backlog aktualisieren, sobald sich die Aufgaben ändern. Das Team kann bei der Entscheidung über Anpassungen auf den vereinbarten Plan zurückgreifen.

Häufig gestellte Fragen zur Sprint-Planung

Was ist der Unterschied zwischen Sprint-Planung und Release-Planung?

Die Sprintplanung konzentriert sich darauf, was Ihr Team während eines Sprints erreichen möchte und wie es diese Arbeit umsetzen wird. Die Release-Planung betrachtet einen längeren Zeithorizont, beispielsweise welche Features über mehrere Sprints hinweg verfügbar sein könnten und wann die Benutzer sie voraussichtlich erhalten werden. Release-Prognosen können sich ändern, wenn Teams weitere Informationen erhalten, während jedes Sprint-Ziel die Arbeit innerhalb des jeweiligen Sprints lenkt.

Benötigen Sie eine „Definition of Ready“ für die Planung des Sprints?

Nein. Scrum verlangt keine formale „Definition of Ready“. Manche Teams nutzen eine solche, um vor der Auswahl gemeinsame Erwartungen an Backlog-Elemente festzulegen, wie z. B. klare Anforderungen, einen überschaubaren Umfang und bekannte Abhängigkeiten. Halten Sie diese Kriterien so flexibel, dass sie die Diskussion unterstützen, ohne das Team daran zu hindern, Elemente bei Bedarf zu verfeinern.

Kann ein Sprint nach dem Plan abgesagt werden?

Ja. Nur der Product Owner kann einen Sprint absagen, und eine Absage ist dann möglich, wenn das Ziel des Sprints hinfällig wird, beispielsweise weil sich geschäftliche Prioritäten oder Marktbedingungen erheblich geändert haben. Eine schwierige Aufgabe oder eine ungenaue Schätzung allein rechtfertigt eine Absage nicht unbedingt.

Was ist der Unterschied zwischen einem Sprint und Agilität?

Agilität ist ein umfassenderer Ansatz zur Arbeitssteuerung, der auf den Werten und Prinzipien des Agilen Manifests basiert. Ein Sprint ist ein festgelegter Zeitraum von maximal einem Monat innerhalb des Scrum-Rahmenwerks, in dem ein Team auf ein Sprint-Ziel hinarbeitet und ein nutzbares Inkrement erstellt. Man kann agile Prinzipien auch ohne Sprints anwenden. Kanban beispielsweise unterstützt einen kontinuierlichen Flow der Arbeit, ohne dass Iterationen fester Länge erforderlich sind.

Kann ein Sprint mehrere Ziele haben?

Scrum definiert ein Sprintziel als das einzige Ziel des Sprints. Sie können Backlog-Elemente auswählen, die andere Prioritäten unterstützen, solange sie dieses Ziel nicht gefährden. Wenn Ihr Team regelmäßig mehrere voneinander unabhängige Ziele benötigt, besprechen Sie vor der Planung, ob die Arbeit zu einem übergeordneten gemeinsamen Ergebnis beiträgt oder ob Sie konkurrierende Prioritäten klären müssen.

Sollten Sie Fehler bei der Planung des Sprints in Story-Punkten abschätzen?

Story-Points sind in Scrum optional, auch für Fehler. Teams, die Fehler einschätzen, sollten sich darauf einigen, wann und warum sie dies tun. Bekannte Mängel können während der Planung bewertet werden, während Fehler, die während der Entwicklung entdeckt werden, möglicherweise unter die Arbeit fallen, die ohnehin erforderlich ist, um die „Definition of Done“ zu erfüllen. Vermeiden Sie es, denselben Aufwand doppelt zu zählen.