Einleitung – Die unsichtbare Metrik für Scrum-Erfolg
Scrum-Teams sollen laut Scrum Guide zwischen 3 und 9 Mitglieder haben.
Das klingt wie eine harmlose Richtlinie – bis man einmal in allen drei Größenordnungen gearbeitet hat.
Ich habe Teams erlebt, die so klein waren, dass man beim Daily schon wusste, was die anderen erzählen werden – und Teams, die so groß waren, dass man im Daily mehr Smalltalk als Fortschritt austauschte.
Ich habe gesehen, wie eine Teamgröße alles beeinflusst: von der Stimmung in der Retro bis hin zur Wahrscheinlichkeit, dass eine Story pünktlich fertig wird.
Und es hängt nicht nur an der Zahl. Ob die Leute T-Shaped (breit aufgestellt, mit einer Kernkompetenz) oder reine Spezialisten sind, macht den Unterschied, ob ein Team flexibel und resilient ist –
oder ob es bei jedem Ausfall im Chaos versinkt.
Lass uns in drei Alltagsszenen eintauchen:
- Ein kleines 3er-Team
- Ein solides 6er-Team
- Ein großes, global verteiltes 9er-Team
Die Charaktere sind dieselben – nur die Teamgröße verändert sich.
Alle arbeiten remote, nutzen Jira für Tickets, Slack für Chat und Teams für Meetings.
Die Charaktere
- Lena – Product Ownerin, strukturiert, liebt klare Sprintziele
- Tom – Senior Dev, T-Shaped, bringt Humor und Erfahrung
- Priya – QA-Engineer, findet jeden Bug, immer
- Max – Frontend Dev, kreativ, manchmal chaotisch
- Sara – Backend Dev, spezialisiert auf Datenbanken, analytisch
- Diego – DevOps, liebt Automatisierung, hasst manuelle Schritte
- Jin – Junior Dev, motiviert, lernt schnell
- Nadia – Backend Dev, ruhig, präzise, liebt sauberen Code
- Omar – Data Engineer, analytisch, eher still, aber treffsicher in Meetings
Szenario 1: Das 3er-Team – Eng verbunden, aber fragil
Teammitglieder: Lena, Tom, Priya
Kurz vor dem Daily
08:57 Uhr.
Slack blinkt. Priya schickt einen GIF von einer Katze, die verzweifelt auf die Uhr schaut.
„Daily in 3 min – und meine Tests sind immer noch rot 🙈“, schreibt sie.
Tom ist schon im Teams-Call. Kamera an, Kaffee in der Hand.
Lena tritt bei: „Moin ihr beiden – kurz und knackig heute, oder?“
Im 3er-Team ist es immer knackig. Jeder weiß, was die anderen tun.
Manchmal kann das fast zu viel Nähe sein – man kennt die Blocker, aber auch jede Frustration des anderen.
Sprintverlauf
Tag 3: Eine Story eskaliert. Ein externer API-Provider hat seine Schnittstelle geändert.
Tom muss alles umbauen.
Priya stoppt ihre Tests, um zu helfen – ihr eigenes Ticket liegt auf Eis.
Das Sprintziel? Schon jetzt gefährdet.
Tag 5: Lena verschiebt zwei Stories in „Next Sprint“.
Niemand ist überrascht. Aber es fühlt sich trotzdem nach Niederlage an.
Sprint Planning
Es dauert 20 Minuten.
Lena: „Wir haben 4 Tickets, die wir anfangen könnten – aber bitte nur eins gleichzeitig.“
Tom und Priya nicken. Sie wissen: Wenn wieder was eskaliert, ist der Sprint gelaufen.
Gefühl im 3er-Team:
Enge Abstimmung, blitzschnelle Kommunikation – aber null Puffer.
Ein Krankheitsfall oder ein Blocker reicht, um das Sprintziel zu kippen.
Szenario 2: Das 6er-Team – Die goldene Mitte
Teammitglieder: Lena, Tom, Priya, Max, Sara, Diego
Kurz vor dem Daily
08:59 Uhr.
Max schreibt im Slack: „Bin 2 min später – Build läuft noch.“
Sara: „Mach keinen Stress, wir sind ja keine Maschine 😉.“
Das Daily dauert jetzt 15 Minuten.
Die Hälfte des Teams weiß nicht mehr automatisch, was die anderen gemacht haben. Das Daily ist jetzt der Ort, um das herauszufinden.
Sprintverlauf
Tag 4: Zwei Stories hängen.
Sara wartet auf ein Frontend-API von Max. Max hat gestern angefangen, parallel an einer anderen Story zu arbeiten.
„Warum?“, fragt Lena im Chat.
„Weil ich da gerade Bock drauf hatte… und das andere war blockiert“, antwortet Max.
Diego ist im Hintergrund still dabei, die CI/CD-Pipeline zu optimieren – seine Arbeit taucht in keinem Sprintziel auf.
Sprint Planning
Diesmal dauert es 45 Minuten.
Es wird mehr diskutiert.
Tom: „Das Sprintziel ist zu breit.“
Lena: „Dann sagt mir, was wir weglassen.“
Niemand will entscheiden – am Ende bleiben alle Stories drin.
Gefühl im 6er-Team:
Ausreichend Puffer, um Ausfälle abzufangen.
Kommunikation ist aber nicht mehr automatisch, sondern muss aktiv organisiert werden.
Sprintziele können verwässern, wenn keiner klare Prioritäten setzt.
Szenario 3: Das 9er-Team – Global verteilt, Konsens als Bremse
Teammitglieder: Lena, Tom, Priya, Max, Sara, Diego, Jin, Nadia, Omar
Kurz vor dem Daily
08:00 Uhr in Berlin, 14:00 Uhr in Singapur, 22:00 Uhr in San Francisco.
Jin sitzt mit Kopfhörern im Coworking-Space, Omar im Halbdunkel seines Home-Offices.
Lena öffnet das Daily: „Okay, Leute, wir sind vollzählig…“
Tom: „Moment, Nadia ist noch im anderen Call.“
Das Daily dauert jetzt 25 Minuten.
Es gibt Smalltalk, viele Status-Updates – und trotzdem weiß man nicht, wer woran genau hängt.
Sprintverlauf
Tag 5:
In Jira tauchen neue Tickets auf, die mitten im Sprint gestartet werden.
Lena schreibt: „Bitte nur Stories anfangen, wenn andere fertig sind.“
Sara reagiert mit einem neutralen Emoji – und startet trotzdem ein neues Ticket.
Das Sprintziel?
Eher eine hübsch formulierte Überschrift für den Stakeholder-Report.
Sprint Planning
Es dauert 1,5 Stunden.
Zeitverschiebung macht die Diskussion zäh.
Jeder will „seine“ Stories unterbringen. Konsens dauert ewig – und führt oft zu Mittelmaß.
Gefühl im 9er-Team:
Hohe Spezialisierung, aber träge Konsensfindung.
Viel Koordination, wenig Fokus.
Echtes Sprintziel? Selten. Motivation sinkt.
Der Wendepunkt – FlightRoom
Nach einer besonders frustrierenden Retro („Wir reden eh immer über dieselben Probleme…“) schlägt Lena vor, den nächsten Team-Workshop mit FlightRoom zu machen.
90 Minuten später sieht es im Teams-Call ganz anders aus:
Auf dem Bildschirm ein virtuelles Cockpit.
Jeder hat eine Rolle – Kapitän, Co-Pilot, Bordingenieur, Tower, Bodentechniker.
Die Stimme des Spielleiters klingt ruhig, aber mit spürbarer Spannung:
„Willkommen im Birgenair 301-Szenario.
Damals endete der Flug in einer Katastrophe. Heute entscheidet eure Crew, wie das ausgeht.“
Der Start läuft reibungslos. Doch bald beginnen die Instrumente, widersprüchliche Werte anzuzeigen.
„Ich sehe zu niedrige Geschwindigkeit!“, ruft Max.
„Nein, das ist ein Fehler. Wir müssen weiter steigen!“, antwortet Sara.
Die Zeit drängt, die Diskussion wird hitzig.
Tom als Kapitän fordert: „Tower, wir brauchen sofort alle Daten, die ihr habt!“
Priya, im Tower, antwortet kurz und präzise – keine langen Erklärungen, nur klare Fakten.
Entscheidungen fallen schnell, abgestimmt, ohne langes Hin und Her.
Nach der Simulation herrscht Ruhe. Alle spüren, wie wichtig offene Kommunikation, klare Ansagen und gegenseitiges Vertrauen sind.
Lena sagt: „Das hat uns gezeigt, wie wir auch im Sprint besser zusammenarbeiten können. Keine langen Diskussionen, sondern fokussiert, direkt, im Team.“
Ergebnis nach dem FlightRoom
Drei Sprints später:
- Stories werden fertig, statt nur angefangen
- Sprintziele sind erreichbar und motivierend
- Die Stimmung ist spürbar besser – auch im großen, verteilten Team
Fazit & Praxis-Tipps
- Teamgröße bewusst wählen:
3–4 Leute: blitzschnell, aber fragil
5–7 Leute: gute Balance, braucht Priorisierung
8–9 Leute: nur mit starker Moderation und klarer Kommunikation effektiv - T-Shaped Skills fördern:
Spezialisten sind wichtig, aber ohne Grundkompetenzen in mehreren Bereichen bricht das Team bei Engpässen ein. - Remote-Arbeit bewusst strukturieren:
Klare Meeting-Zeiten, gemeinsame Tools, kurze Feedback-Loops - Gemeinsame Ziele priorisieren:
Ein Sprintziel, das allen wichtig ist, bringt mehr als 5 Einzelziele - FlightRoom einsetzen:
Kommunikation so trainieren, dass auch große Teams effektiv Entscheidungen treffen und sich gegenseitig unterstützen