Sprint-Planung für kleine Teams: ein schlanker 45-Minuten-Ablauf

Sprint-Planung heißt: Das Team legt fest, was in den nächsten ein bis zwei Wochen fertig wird – und in welcher Reihenfolge. Nach Scrum-Lehrbuch sind dafür bis zu zwei Stunden je Sprint-Woche vorgesehen; für ein Team aus drei bis fünf Leuten ist das deutlich zu viel Zeremonie. Dieser Beitrag zeigt einen Ablauf, der in 45 Minuten durch ist, ohne die Substanz zu verlieren: Rückblick, Ziel, Auswahl, Blocker-Check, Start.

Wozu Sprints, wenn ihr klein seid?

Die ehrliche Vorfrage zuerst. Sprints – in IssuePilot heißen sie Zyklen – bringen drei Dinge: einen Rhythmus, der Anfang und Ende erzeugt, einen Schutzraum gegen ständiges Umpriorisieren und einen regelmäßigen Moment, in dem das Team auf das Geleistete schaut. Wer dagegen fast nur reaktiv arbeitet – Support, Wartung, viele kleine Kundenaufträge –, fährt mit einem kontinuierlichen Ablauf oft besser: Eingang, Priorität, Board oder Liste, fertig. Sprints lohnen sich, sobald es planbare Vorhaben gibt, die größer sind als ein Tag.

Die Vorbereitung: 15 Minuten am Vortag

Die häufigste Ursache zäher Planungsrunden liegt vor der Runde: Das Team sortiert live ein unaufgeräumtes Backlog. Das lässt sich vermeiden, wenn eine Person – wer auch immer bei euch die Produktrolle trägt – am Vortag drei Dinge erledigt:

• Das Backlog oben aufräumen: Die obersten 15 bis 20 Einträge sind aktuell, verständlich und nachvollziehbar priorisiert.
• Den Eingang leeren: Neue Meldungen sind triagiert – nichts Ungeprüftes wandert direkt in die Planung.
• Reste entscheiden: Was aus dem letzten Sprint offen ist, wird bewusst mitgenommen oder zurück ins Backlog gelegt – nicht stillschweigend weitergeschleppt.

Der Ablauf: fünf Schritte in 45 Minuten

1. Rückblick in Zahlen (5 Minuten)

Kein Rechtfertigungsritual, nur Kalibrierung: Wie viel wurde im letzten Sprint tatsächlich fertig? Diese eine Zahl ist die beste Grundlage für die Frage, wie viel diesmal hineinpasst. Teams überschätzen sich systematisch – der Blick auf die letzte Runde korrigiert das zuverlässiger als jede Diskussion.

2. Sprint-Ziel formulieren (5 Minuten)

Ein Satz, der beschreibt, was am Ende anders ist: „Der neue Checkout ist für interne Tests bereit.“ Das Ziel ist kein Sammelbegriff für alle Aufgaben, sondern der Kern, an dem sich Konflikte entscheiden. Wenn mittendrin etwas Neues hereinkommt, lautet die Frage nicht „haben wir Zeit?“, sondern „bringt uns das dem Satz näher?“.

3. Aufgaben ziehen (15 Minuten)

Von oben nach unten durch das vorbereitete Backlog, Aufgabe für Aufgabe: Gehört sie zum Ziel? Ist sie klein genug, um in dieser Runde fertig zu werden? Wer große Brocken zieht, zerlegt sie jetzt – eine Aufgabe, die länger als zwei, drei Tage dauert, versteckt meist mehrere. Gezogen wird, bis die Kapazität erreicht ist, dann ist Schluss. Der schwerste Teil dieses Schritts ist das Aufhören.

4. Blocker-Check (10 Minuten)

Jede gezogene Aufgabe bekommt eine kurze Frage: Wartet sie auf etwas – eine andere Aufgabe, eine Freigabe, eine Zulieferung? Wenn ja, wird die Abhängigkeit als Blocker-Beziehung verknüpft, und die Reihenfolge folgt daraus: Was andere freigibt, zieht nach vorn; was auf Externes wartet, wird sofort angestoßen, damit die Wartezeit nicht in den Sprint fällt. Diese zehn Minuten ersetzen das Krisen-Standup am Mittwoch.

cockpit.issuepilot.app/issues

5. Zuständigkeiten und Start (10 Minuten)

Nicht jede Aufgabe braucht jetzt einen Namen – aber jede Person braucht ihre erste. Der Rest bleibt im Sprint und wird gezogen, sobald jemand frei ist. Damit ist die Planung vorbei, und das Board übernimmt.

cockpit.issuepilot.app/board

Kapazität realistisch schätzen

Für den dritten Schritt braucht es eine Zahl, und dafür reicht eine Faustregel, die sich in kleinen Teams bewährt hat: verfügbare Personen mal Arbeitstage mal 0,6. Drei Leute in einem Zwei-Wochen-Sprint ergeben 3 × 10 × 0,6 = 18 produktive Tage. Die 0,6 sind kein Pessimismus, sondern Erfahrung: Meetings, Rückfragen, kleine Störungen und der Support-Anteil fressen verlässlich ihren Teil. Wer eine Support-Woche hat, zählt halb. Storypoints braucht ihr dafür nicht – grobe Tagesschätzungen je Aufgabe reichen, solange dieselbe Person schätzt, die umsetzt.

Während des Sprints: die Tausch-Regel

Ein Sprint schützt nur, wenn er nicht täglich neu verhandelt wird. Neues landet im Eingang und wartet auf die nächste Runde. Für echte Notfälle gilt die Tausch-Regel: Kommt etwas Unaufschiebbares herein, fliegt etwas gleich Großes raus – sichtbar, mit Ansage. Das hält den Umfang ehrlich und macht die Kosten der Unterbrechung sichtbar, statt sie in Überstunden zu verstecken.

Das Sprint-Ende: Review light

Eine halbe Stunde reicht: zeigen, was fertig ist – am liebsten am lebenden Produkt, nicht in Folien –, Unfertiges bewusst zurücklegen und zwei Retro-Fragen beantworten: Was hat uns gebremst? Was machen wir nächste Runde anders? Wer mag, wirft einen Blick auf die Durchlaufzeiten und erledigten Aufgaben pro Woche, um Trends zu erkennen.

cockpit.issuepilot.app/insights

Häufige Fehler

• Den Sprint zu 100 % füllen: Ohne Puffer kippt die erste Störung den ganzen Plan.
• Kein Ziel, nur eine Liste: Dann fehlt der Maßstab, wenn unterwegs priorisiert werden muss.
• Reste stillschweigend mitnehmen: Unfertiges wandert von Sprint zu Sprint, bis niemand mehr an Zusagen glaubt.
• Planen ohne die Umsetzenden: Geschätzt wird von denen, die die Arbeit machen – sonst stimmt keine Zahl.
• Notfälle on top nehmen: Ohne Tausch-Regel wird der Sprint zur Wunschliste mit Ablaufdatum.

In IssuePilot bildet ihr diesen Ablauf mit Zyklen ab: Aufgaben in den Zyklus ziehen, Blocker verknüpfen, Fortschritt im Board verfolgen und in den Insights sehen, was der Takt bringt. Zyklen und Insights gehören zum Pro-Plan – bei der Registrierung sind alle Pro-Funktionen 30 Tage enthalten, sodass ihr den Ablauf mit echtem Projekt testen könnt. Wie das Zusammenspiel für Entwicklerteams aussieht, zeigt die Seite für Software-Teams.