Kurze, nützliche Teammeetings haben drei Dinge gemeinsam: eine schriftliche Agenda mit einem Zeitbudget pro Punkt, ein klares Ende und ein Ergebnis, mit dem jemand weiterarbeitet. Realistische Sprintplanung hat noch eine vierte Eigenschaft: Das Team verpflichtet sich zu dem, was die letzten Sprints hergeben – angepasst an die tatsächlich verfügbaren Personen –, und nicht zu dem, was es sich erhofft.
Die meisten Teams starten nicht mit langen Meetings, sie rutschen hinein: Das Standup wird zum Statusbericht, Probleme werden in der Runde gelöst, während sechs Leute warten, und das Planning wird zur Verhandlung, die die optimistischste Schätzung gewinnt. Dieser Leitfaden zeigt in vier Schritten, wie ihr gegensteuert – mit vier kostenlosen Tools auf kimisuite.com. Für keines davon braucht ihr ein Konto.
Schritt 1: Die Agenda schreiben, bevor die Einladung rausgeht
Der Meeting Agenda Generator bietet sechs Vorlagen: Daily Standup, Sprint-Retrospektive, All-Hands, 1:1, Sales-Discovery-Call und Projekt-Kickoff. Ihr gebt einen Titel, die Länge des Termins und die moderierende Person ein und kopiert das Ergebnis oder ladet es als Markdown herunter.
Die Standup-Vorlage sieht so aus:
- Gestern: Erfolge und Hindernisse (5 Min.)
- Heute: Prioritäten (5 Min.)
- Blocker und Anliegen (5 Min.)
- Eine Sache, die niemand weiß (eine Runde à eine Minute)
Die Retrospektiven-Vorlage kommt auf 42 Minuten: Einstieg (5), was gut lief (10), was nicht gut lief (10), konkrete Maßnahmen mit Verantwortlichen und Termin (15) sowie ein kurzer Energie-Check von 1 bis 5 (2).
Ein Detail, das man kennen sollte: Die Zeiten der Abschnitte sind pro Vorlage fest. Die eingegebene Länge erscheint zwar im Kopfbereich, die Abschnitte werden aber nicht neu skaliert. Ist euer Retro-Termin nur 30 Minuten lang, kürzt sie von Hand, bevor ihr einladet. Genau darum geht es: Ihr entscheidet vorab, was weniger Zeit bekommt.
Schritt 2: Das Standup auf 15 Minuten begrenzen
Der Scrum Guide (Version November 2020, scrumguides.org) beschreibt das Daily Scrum als "ein 15-minütiges Event für die Developers", das "an jedem Arbeitstag des Sprints zur selben Zeit und am selben Ort" stattfindet. Sein Zweck ist es, den Fortschritt in Richtung Sprint-Ziel zu überprüfen und den Plan für die anstehende Arbeit anzupassen.
Derselbe Guide sagt auch, dass die Developers "jede beliebige Struktur und Technik wählen können". Die drei klassischen Fragen sind eine Gewohnheit, keine Regel. Wenn "Was hast du gestern gemacht?" zum Aufsagen geworden ist, ändert die Frage.
Dabei hilft der Standup Question Generator. Er wählt 1 bis 10 zufällige Fragen aus einem von vier Fragenpools: Eisbrecher, Retrospektive, Tiefgang und Spaß. Eröffnet das Standup einmal pro Woche mit einer Eisbrecherfrage oder bringt Retro-Fragen wie "Wo hast du am meisten Zeit verloren?" oder "Womit müssen wir AUFHÖREN?" in die Retrospektive mit.
Schritt 3: Stories vor dem Planning schätzen
Das Planning geht schneller, wenn die Stories bereits eine Größe haben. Der Story Point Estimator ist eine Solo-Version von Planning Poker. Ihr wählt Fibonacci (1, 2, 3, 5, 8, 13, 21, 40, 100) oder T-Shirt-Größen (XS bis XXL, plus "?"), tippt die Story ein, wählt eine Karte und stellt eure Sicherheit auf niedrig, mittel oder hoch. Die Schätzungen landen in einer fortlaufenden Liste mit Punktesumme.
Der eigentliche Mehrwert sind die Hinweise unter jeder Karte. Bei 13 steht "Groß · vor dem Commitment aufteilen", bei 21 "Zu groß · in kleinere Stories zerlegen", und "?" bedeutet, dass ihr vor der Schätzung mehr Informationen braucht. Wenn ihr 13 oder mehr wählt, ist die Story noch nicht reif für den Sprint.
Solo-Schätzungen sind ein Ausgangspunkt. Das Team bespricht sie trotzdem, denn eine Person allein übersieht, was die anderen wissen.
Schritt 4: Den Sprint aus der eigenen Velocity prognostizieren
Der Scrum Guide erwähnt weder Velocity noch Story Points. Er sagt aber: Je mehr die Developers über "ihre bisherige Leistung, ihre kommende Kapazität und ihre Definition of Done" wissen, "desto sicherer werden ihre Sprint-Prognosen sein". Velocity, also die Punkte, die ein Team pro Sprint abgeschlossen hat, ist eine verbreitete Methode, das zu messen.
Der Sprint Velocity Calculator nimmt eure letzten drei Sprints und eure Kapazität für den nächsten Sprint in Prozent und liefert:
- Den Durchschnitt der drei Sprints
- Einen Trend: steigend, wenn der letzte Sprint mehr als 10 Prozent über dem vorherigen lag, fallend, wenn er mehr als 10 Prozent darunter lag, sonst stabil
- Eine Prognose: den Durchschnitt multipliziert mit eurer Kapazität
- Wie viele Sprints es dauert, 50 Punkte abzuschließen, ausgehend von dieser Prognose
Ein Rechenbeispiel
Ein fünfköpfiges Team hat in seinen letzten drei Sprints 24, 31 und 27 Punkte abgeschlossen. Eine Person ist den gesamten nächsten Sprint im Urlaub, die Kapazität liegt also bei 80 Prozent.
- Durchschnitt: (24 + 31 + 27) / 3 = 27,3 Punkte
- Trend: 27 liegt mehr als 10 Prozent unter 31, daher zeigt der Rechner "Fallender Trend – Blocker untersuchen"
- Prognose: 27,3 x 0,8 = 21,8 Punkte
- Sprints bis 50 Punkte: 50 / 21,8 = 2,3, aufgerundet 3
Nehmt nun die geschätzten Stories aus Schritt 3: 8, 5, 5, 3 und 2 Punkte, insgesamt 23. Das liegt über der Prognose von 21,8. Der ehrliche Plan lautet 8 + 5 + 5 + 3 = 21 Punkte – die 2-Punkte-Story wird als Erste nachgezogen, falls das Team früher fertig ist.
Der Trend vergleicht nur die letzten beiden Sprints, ein einziger holpriger Sprint reicht also für "fallend". Fragt in der Retrospektive nach, was im Weg stand, bevor ihr darin ein Problem seht. Und vergleicht Velocity niemals zwischen Teams: Die Punkte jedes Teams bedeuten etwas anderes.
Wo KIMISUITE ins Spiel kommt
Die Tools funktionieren eigenständig. Wenn ihr Meetings und Sprint-Board an einem Ort haben wollt, decken zwei KIMISUITE-Apps die obigen Schritte ab.
Meeting Hub ermöglicht Videomeetings, denen Gäste per Link im Browser beitreten. Beim Planen eines Meetings könnt ihr die Agenda in die Beschreibung einfügen. Im Call bietet das Tools-Menü einen Timer (1, 5, 10, 15, 30 Minuten oder individuell), den alle sehen und der bei 0:00 rot wird. Eine Umfrage mit zwei oder mehr Optionen hilft der Retro zu entscheiden, welche Maßnahme zuerst angegangen wird. Nach dem Meeting lässt sich das Transkript in jedem Tarif herunterladen, und in Pro und Enterprise listet eine KI-Zusammenfassung die Maßnahmen mit Zuständigkeit und Frist sowie die getroffenen Entscheidungen auf.
Task Hub enthält den Sprint selbst. Die Vorlage Engineering Sprint legt Listen, Labels und Beispielkarten für ein neues Board an. Ab dem Grow-Tarif könnt ihr benutzerdefinierte Felder wie ein Zahlenfeld hinzufügen und Abhängigkeiten setzen, sodass eine Karte zeigt, was sie blockiert oder wovon sie blockiert wird. Im Business-Tarif kann AI Task aus Zusammenfassung und Transkript eines abgeschlossenen Meeting-Hub-Meetings Kartenvorschläge erstellen, die ihr prüft, bevor sie angelegt werden. Mehr dazu in Task Hub: von der Sprachnotiz zum Task-Board.
Beide Apps befinden sich im selben KIMISUITE-Workspace, der pro Workspace abgerechnet wird, nicht pro Nutzer. Was das für ein Team bedeutet, lest ihr unter Preise pro Workspace, nicht pro Nutzer. Jede App lässt sich 14 Tage lang testen.
FAQ
Was tun, wenn unser Standup immer länger als 15 Minuten dauert?
Lagert die Problemlösung aus. Braucht ein Thema mehr als eine Minute, benennt es, benennt die zwei Personen, die darüber sprechen müssen, und lasst sie direkt im Anschluss zusammenkommen.
Müssen wir die drei Standup-Fragen verwenden?
Nein. Laut Scrum Guide 2020 wählen die Developers die Struktur selbst, solange das Meeting den Fortschritt in Richtung Sprint-Ziel überprüft und den Plan anpasst. Eine andere Frage pro Woche verhindert, dass die Runde zum Bericht wird.
Wie viele Sprints brauche ich, um die Velocity zu berechnen?
Der Sprint Velocity Calculator verwendet die letzten drei. Weniger Sprints ergeben einen schwankenden Durchschnitt; sehr alte Sprints beschreiben ein Team, das sich inzwischen verändert haben kann.
Welche Kapazität gebe ich ein, wenn jemand nur einen Teil des Sprints fehlt?
Schätzt den Anteil der Arbeitstage des Teams, der tatsächlich verfügbar ist. In einem fünfköpfigen Team entspricht eine Person, die den ganzen Sprint fehlt, 80 Prozent. Fehlt eine Person drei Tage eines zehntägigen Sprints, sind das 47 von 50 Personentagen, also rund 94 Prozent.
