Scrum für kleine Teams
Du hast drei bis sieben Leute im Team, einen Haufen Ideen und den Wunsch, strukturiert zu arbeiten? Dann ist Scrum vielleicht genau das Richtige für dich -- wenn du es richtig adaptierst. Denn das klassische Scrum-Framework wurde für Teams von sieben bis neun Personen konzipiert. Für ein Drei-Personen-Startup muss man es anpassen.
In diesem Beitrag zeige ich dir, wie du Scrum für kleine Teams zum Laufen bringst -- ohne den Overhead, der grössere Organisationen oft ausbremst.
Scrum im Schnelldurchlauf
Falls du Scrum noch nicht kennst, hier die Kurzfassung:
Die drei Rollen
- Product Owner: Entscheidet, WAS gebaut wird. Verwaltet das Product Backlog und priorisiert die Aufgaben.
- Scrum Master: Sorgt dafür, DASS der Prozess funktioniert. Räumt Hindernisse aus dem Weg.
- Entwicklungsteam: Entscheidet, WIE die Aufgaben umgesetzt werden.
Die fünf Events
- Sprint: Ein fester Zeitrahmen (meist 1-4 Wochen) für die Arbeit
- Sprint Planning: Planung der Arbeit für den nächsten Sprint
- Daily Scrum: Tägliches 15-Minuten-Standup
- Sprint Review: Vorstellung der Ergebnisse am Sprint-Ende
- Sprint Retrospektive: Reflexion über den Arbeitsprozess
Die drei Artefakte
- Product Backlog: Die priorisierte Liste aller gewünschten Features
- Sprint Backlog: Die Aufgaben für den aktuellen Sprint
- Increment: Das fertige Ergebnis am Ende des Sprints
Das Problem: Scrum und kleine Teams
Wenn du zu dritt oder zu viert an deinem Startup arbeitest, stossen manche Scrum-Elemente an ihre Grenzen:
Rollenkonflikte
Bei drei Personen bräuchtest du theoretisch einen Product Owner, einen Scrum Master und einen Entwickler. Das ist offensichtlich absurd -- du hast ja kaum Entwicklungskapazität übrig.
Meeting-Overhead
Fünf formale Events pro Sprint können bei einem kleinen Team schnell einen erheblichen Teil der verfügbaren Arbeitszeit auffressen. Wenn du zu dritt arbeitest und zwei Stunden pro Tag in Meetings sitzt, fehlt dir ein Drittel deiner Produktivität.
Formalismus
Viele Scrum-Praktiken -- wie aufwändige Story-Point-Schätzungen oder detaillierte Burndown-Charts -- lohnen sich bei kleinen Teams schlicht nicht.
Scrum Light: Das adaptierte Framework
Hier ist mein erprobter Ansatz für Scrum in kleinen Startup-Teams:
Rollen zusammenlegen -- aber bewusst
In einem kleinen Team trägst du mehrere Hüte. Das ist okay, solange du dir dessen bewusst bist.
Empfehlung für Teams von 3-4 Personen:
- Gründer/CEO als Product Owner: Du kennst die Vision, du kennst den Markt. Die Product-Owner-Rolle liegt natürlich bei dir.
- Rotating Scrum Master: Wechselt die Scrum-Master-Rolle wöchentlich oder pro Sprint. So lernt jeder, den Prozess zu moderieren, und niemand wird zum Vollzeit-Prozesswächter.
- Alle sind Entwickler: Jeder im Team arbeitet auch an der Umsetzung -- einschliesslich des Product Owners.
Beispiel aus einem Grazer Startup: Ein Drei-Personen-Team aus dem EdTech-Bereich hat es so gelöst: Die Gründerin war Product Owner und Entwicklerin (70/30 Aufteilung), der CTO war Scrum Master und Entwickler (20/80), und die dritte Person war Vollzeit-Entwicklerin. Das funktionierte, weil die Rollen klar definiert waren.
Sprints: Kürzer ist besser
Für kleine Teams empfehle ich einwöchige Sprints. Warum?
- Schnelleres Feedback: Du lernst jede Woche dazu
- Weniger Planungsaufwand: Eine Woche lässt sich leichter überblicken
- Höhere Flexibilität: Du kannst schneller auf neue Erkenntnisse reagieren
Manche österreichische Startups, die ich begleitet habe, arbeiten sogar mit dreitägigen Sprints in der Frühphase. Das ist extrem kurz, kann aber in der Validierungsphase sehr wertvoll sein.
Meetings verschlanken
Hier ist mein Meeting-Setup für kleine Teams:
Montag: Sprint Planning (30-45 Minuten)
- Backlog-Review: Was ist am wichtigsten?
- Sprint-Ziel definieren: Was wollen wir diese Woche erreichen?
- Aufgaben verteilen: Wer macht was?
Täglich: Standup (5-10 Minuten)
- Kurz und knackig, im Stehen
- Bei Remote-Teams: Slack-Update statt Video-Call (spart Zeit)
- Fokus auf Hindernisse: "Was blockiert mich?"
Freitag: Review und Retro kombiniert (45-60 Minuten)
- Erste Hälfte: Was haben wir geschafft? Demo der Ergebnisse.
- Zweite Hälfte: Was lief gut? Was können wir verbessern?
Das sind insgesamt etwa 2,5 Stunden pro Woche für Meetings. Das ist machbar und lässt genügend Zeit für produktive Arbeit.
Das Backlog schlank halten
Ein aufgeblähtes Backlog ist der Feind kleiner Teams. Hier sind meine Regeln:
Die 20-Item-Regel
Halte dein Product Backlog auf maximal 20 Items. Alles darüber hinaus kommt in eine "Ideen-Parkplatz"-Liste, die du einmal im Monat reviewst.
User Stories einfach halten
Du brauchst keine perfekten User Stories mit Akzeptanzkriterien, Story Points und Definition of Done. Für kleine Teams reicht oft:
Als [Nutzer] will ich [Funktion], damit [Nutzen].
Aufgaben:
- [ ] Backend-Logik implementieren
- [ ] Frontend anpassen
- [ ] TestenT-Shirt-Sizing statt Story Points
Statt aufwändiger Story-Point-Schätzungen nutze T-Shirt-Grössen:
- S: Ein paar Stunden Arbeit
- M: Ein bis zwei Tage
- L: Drei bis fünf Tage
- XL: Muss in kleinere Aufgaben aufgeteilt werden
Das reicht völlig aus, um die Sprint-Kapazität zu planen.
Praktische Tools für kleine Teams
Du brauchst kein teures Projektmanagement-Tool. Hier sind Optionen für verschiedene Budgets:
Kostenlos (0 EUR)
- Trello: Einfaches Kanban-Board, kostenlos für kleine Teams
- GitHub Projects: Wenn du bereits auf GitHub entwickelst, ist das integrierte Projektmanagement völlig ausreichend
- Notion: Kombiniert Dokumentation und Projektmanagement
Günstig (unter 50 EUR pro Monat)
- Linear: Schnelles, modernes Issue-Tracking -- beliebt bei Tech-Startups
- Shortcut (ehemals Clubhouse): Guter Mittelweg zwischen einfach und mächtig
- Jira (Cloud): Der Klassiker -- oft überdimensioniert für kleine Teams, aber kostenlos für bis zu 10 Nutzer
Mein Tipp für den Start
Starte mit einem physischen Board, wenn ihr im selben Büro sitzt. Ein Whiteboard mit Post-its ist immer noch eines der besten Scrum-Tools -- es ist sichtbar, anfassbar und zwingt euch zur Einfachheit.
Wenn dein Team remote arbeitet -- was im Burgenland mit seiner ländlichen Struktur häufig vorkommt -- ist Trello oder Linear ein guter Startpunkt.
Scrum-Metriken für kleine Teams
Vergiss komplexe Velocity-Charts und Burndown-Diagramme. Für kleine Teams reichen diese drei Metriken:
1. Sprint-Zielerreichung
Habt ihr das Sprint-Ziel erreicht? Ja oder nein? Das ist die wichtigste Metrik. Wenn ihr regelmässig eure Sprint-Ziele verfehlt, plant ihr zu viel ein.
2. Cycle Time
Wie lange dauert es von "Aufgabe begonnen" bis "Aufgabe fertig"? Wenn diese Zahl steigt, habt ihr ein Problem -- vielleicht sind die Aufgaben zu gross oder es gibt zu viele Blockaden.
3. Team-Zufriedenheit
Fragt am Ende jeder Retrospektive: "Wie zufrieden bist du auf einer Skala von 1-5 mit der letzten Woche?" Trackt diesen Wert über die Zeit. Wenn er sinkt, stimmt etwas nicht.
Häufige Fragen und Probleme
"Wir sind nur zu zweit -- funktioniert Scrum überhaupt?"
Ehrlich gesagt: Bei zwei Personen würde ich eher zu Kanban raten. Scrum lebt von der Teamdynamik, und bei zwei Personen ist das schwierig. Aber einige Scrum-Elemente -- wie wöchentliche Sprints und Retrospektiven -- sind auch zu zweit wertvoll.
"Unser Product Owner hat keine Zeit für Backlog-Pflege"
Das ist ein Klassiker in kleinen Teams. Lösung: Blocke 30 Minuten pro Woche für Backlog-Grooming. Mach es direkt vor dem Sprint Planning. Wenn der Product Owner nicht einmal 30 Minuten pro Woche für die Priorisierung hat, stimmt etwas Grundlegendes nicht.
"Die Retrospektive fühlt sich erzwungen an"
Das passiert oft, wenn man immer das gleiche Format nutzt. Variiere die Retro-Formate:
- Mad/Sad/Glad: Was hat dich geärgert? Was macht dich traurig? Was hat dich gefreut?
- Start/Stop/Continue: Was sollten wir anfangen? Aufhören? Beibehalten?
- Segelboot: Was treibt uns an (Wind)? Was bremst uns (Anker)?
"Wir werden ständig von dringenden Aufgaben unterbrochen"
Führe einen "Interrupt-Buffer" ein: Plane 20-30 Prozent der Sprint-Kapazität für ungeplante Aufgaben ein. So hast du Puffer für dringende Kundenanfragen oder kritische Bugs, ohne den Sprint zu sprengen.
Ein Beispiel-Sprint für ein Vier-Personen-Team
So könnte eine typische Sprint-Woche in deinem Startup aussehen:
Montag:
- 09:00 -- Sprint Planning (30 Min)
- 09:30 -- Arbeit an Sprint-Aufgaben
- Nachmittag -- Fokuszeit
Dienstag bis Donnerstag:
- 09:00 -- Daily Standup (10 Min)
- Rest des Tages -- Fokuszeit für Sprint-Aufgaben
Freitag:
- 09:00 -- Daily Standup (10 Min)
- 14:00 -- Sprint Review + Retro (60 Min)
- 15:00 -- Backlog-Grooming für nächste Woche (30 Min)
Das ergibt rund 35 Stunden produktive Arbeitszeit pro Person bei einer 40-Stunden-Woche. Nicht schlecht.
Wann Scrum nicht passt
Scrum ist nicht für jedes Startup die richtige Wahl. Überleg dir Alternativen, wenn:
- Dein Team weniger als drei Personen hat
- Eure Arbeit nicht in diskrete Aufgaben teilbar ist (z.B. reine Sales-Teams)
- Ihr in einer Phase seid, in der sich eure Prioritäten täglich ändern
- Euer Produkt noch so unklar ist, dass wöchentliche Planung nicht möglich ist
In diesen Fällen kann Kanban die bessere Wahl sein -- mehr dazu im nächsten Beitrag dieser Serie.
Fazit
Scrum für kleine Teams funktioniert -- wenn du es anpasst. Die Kernbotschaften:
- Rollen zusammenlegen ist okay, solange die Verantwortlichkeiten klar sind
- Kurze Sprints (eine Woche) geben dir maximale Flexibilität
- Meetings verschlanken -- kombiniere, was sich kombinieren lässt
- Einfache Metriken reichen völlig aus
- Werkzeuge einfach halten -- ein Whiteboard kann genügen
Das Ziel ist nicht, Scrum perfekt nach Lehrbuch umzusetzen. Das Ziel ist, einen Rhythmus zu finden, der deinem Team hilft, fokussiert und effektiv zu arbeiten. Probier es aus, passe es an, und mach es zu eurem eigenen Framework.
Über Startup Burgenland
Startup Burgenland ist die zentrale Anlaufstelle für Gründerinnen und Gründer im Burgenland. Wir unterstützen dich mit Beratung, Vernetzung und Ressourcen auf deinem Weg zum erfolgreichen Startup. Egal ob du noch in der Ideenphase steckst oder bereits dein Produkt skalierst -- wir sind für dich da. Besuche uns auf unserer Website oder komm zu einem unserer Events, um die burgenländische Startup-Community kennenzulernen.
Hinweis zur Serie: Dieser Beitrag ist Teil 567 der Serie "Agiles Arbeiten und Projektmanagement". In dieser Serie behandeln wir alle Aspekte moderner Arbeitsmethoden -- von den Grundlagen bis zu fortgeschrittenen Techniken -- speziell zugeschnitten auf die Bedürfnisse von Startups und jungen Unternehmen in Österreich.
Über den Autor: Felix Lenhard ist Program Director und Startup Coach bei Startup Burgenland. Zuvor Managing Director beim 360 Innovation Lab, Innovation Manager bei RHI Magnesita und Serial Entrepreneur mit internationalen Exits. Über 15 Jahre Erfahrung in Innovation und Unternehmensaufbau.