Scrum einfach erklärt: Rollen, Events und Artefakte

Dein Team arbeitet an vier Projekten gleichzeitig. Fertig ist keines. Den Zwischenstand bekommst du nur, wenn du danach fragst — und er stimmt selten. Am Quartalsende hast du drei Präsentationen und kein Ergebnis.

Ich sehe das in fast jedem Unternehmen, das ich begleite. Nicht weil die Leute faul sind. Sondern weil niemand definiert hat, wann etwas fertig ist, wer entscheidet und in welchem Takt geliefert wird.

Genau dagegen ist Scrum gebaut. Ein Rahmen mit drei Rollen, fünf Terminen und drei Arbeitsergebnissen. Mehr nicht. Wer das erste Mal in den offiziellen Regeltext schaut, wundert sich: keine 20 Seiten. Der ganze Rest — Poker-Karten, Klebezettel, zertifizierte Berater — ist Zubehör, nicht Substanz.

Dieser Artikel ist der Einstieg in unseren gesamten Projektmanagement-Bereich. Du bekommst hier den kompletten Rahmen: Herkunft, Rollen, Artefakte, Events, den Ablauf eines Sprints, die typischen Fehler im Mittelstand — und am Ende die Übersicht, welcher weiterführende Artikel welche Frage beantwortet. Wenn du erst noch die Grundlagen brauchst, wie Projekte neben dem Tagesgeschäft überhaupt organisiert werden, lies vorher Projektmanagement.

Was ist Scrum?

Scrum ist ein Rahmenwerk, mit dem ein kleines Team komplexe Aufgaben in festen, kurzen Zyklen bearbeitet und am Ende jedes Zyklus ein benutzbares Ergebnis liefert. Diese Zyklen heißen Sprints und dauern maximal einen Monat. Punkt. Das ist die ganze Idee.

Der Kern dahinter: Bei komplexen Vorhaben kannst du nicht vorab alles durchplanen. Du weißt am Anfang nicht genug. Also planst du kurz, lieferst schnell, schaust dir das Ergebnis an und korrigierst. Nicht einmal am Projektende, sondern alle zwei bis vier Wochen. Der Plan ist nicht das Heiligtum — das Ergebnis ist es.

Woher Scrum kommt

Der Begriff stammt aus dem Rugby. Das „Scrum" ist dort das angeordnete Gedränge, in dem die Mannschaft den Ball gemeinsam nach vorn bewegt. 1986 benutzten die japanischen Wissenschaftler Hirotaka Takeuchi und Ikujiro Nonaka dieses Bild in einem Aufsatz für die Harvard Business Review, um zu beschreiben, wie erfolgreiche Produktteams arbeiten: nicht als Staffellauf mit Übergaben zwischen Abteilungen, sondern als eine Einheit, die zusammen läuft.

Ken Schwaber und Jeff Sutherland machten daraus in den 90er-Jahren ein konkretes Vorgehen und stellten es 1995 erstmals öffentlich vor. 2001 gehörten beide zu den 17 Unterzeichnern des Agilen Manifests — vier Wertepaare auf einer halben Seite, bis heute unverändert online. Den verbindlichen Regeltext pflegen Schwaber und Sutherland bis heute selbst: der Scrum Guide ist die einzige Quelle, die festlegt, was zum Rahmen gehört und was nicht.

Rahmenwerk, nicht Methode

Ein wichtiger Unterschied, an dem viele scheitern: Der Rahmen sagt dir nicht, wie du arbeitest. Er sagt dir, wann ihr redet, wer entscheidet und was am Ende vorliegen muss. Wie ihr programmiert, textet, konstruiert oder verkauft — das bleibt eure Sache.

Deshalb ist der Rahmen absichtlich unvollständig. Er ist ein Gerüst, in das du deine eigenen Praktiken hängst. Und er ist nicht in Teilen zu haben: Wer die Retrospektive streicht, weil „dafür keine Zeit ist", betreibt kein Scrum mehr, sondern Projektarbeit mit englischen Vokabeln. Genau das passiert im Mittelstand am häufigsten.

Die drei Säulen und die fünf Werte

Der Rahmen steht auf drei Säulen: Transparenz, Überprüfung und Anpassung. Und er funktioniert nur, wenn fünf Werte im Team gelebt werden: Commitment, Fokus, Offenheit, Respekt und Mut.

Transparenz heißt: Alle Beteiligten sehen denselben Stand. Kein Team hat einen inoffiziellen zweiten Plan, kein Chef eine eigene Liste in der Schublade. Was nicht sichtbar ist, kann nicht bewertet werden.

Überprüfung heißt: Ihr schaut regelmäßig auf Ergebnis und Fortschritt — nicht auf Aktivität. Nicht „wir haben viel gemacht", sondern „das hier ist fertig, schau es dir an".

Anpassung heißt: Wenn die Überprüfung zeigt, dass ihr danebenliegt, ändert ihr sofort etwas. Nicht beim nächsten Lenkungskreis in sechs Wochen.

Und die fünf Werte? Commitment heißt, sich auf das Sprint-Ziel festzulegen statt auf halbe Absichten. Fokus heißt, im Sprint an dem zu arbeiten, was im Sprint drinsteht — und an nichts anderem. Offenheit heißt, Probleme zu benennen, solange sie noch klein sind. Respekt heißt, dass Fachkompetenz vor Hierarchie geht. Und Mut heißt, unangenehme Wahrheiten auszusprechen, bevor sie teuer werden.

Die Werte klingen nach Poster im Flur, sind aber der Grund, warum der Rahmen bei manchen trägt und bei anderen nicht. Mut heißt zum Beispiel, im Sprint Review zu sagen: „Das hier funktioniert nicht, wir werfen es weg." In einer Kultur, in der Fehler Karriere kosten, sagt das niemand. Dann liefert dir auch der beste Rahmen nichts. Wie du eine Kultur aufbaust, in der so etwas möglich ist, steht in Unternehmenskultur.

Die drei Scrum-Rollen im Überblick

Scrum kennt genau drei Verantwortlichkeiten: Product Owner, Scrum Master und Entwickler. Zusammen bilden sie das Team — laut Regeltext zehn Personen oder weniger. Es gibt keinen Projektleiter, keine Teilprojektleiter, keine Lenkungsausschüsse. Das ist für viele Mittelständler die härteste Umstellung.

Product Owner

Der Product Owner verantwortet den Wert des Ergebnisses. Er entscheidet, was gebaut wird und in welcher Reihenfolge — und zwar allein. Er pflegt das Product Backlog, formuliert das Produktziel und ist der Ansprechpartner für alle, die etwas wollen: Vertrieb, Geschäftsführung, Kunden. Eine Person, nicht ein Gremium. Wenn drei Leute die Reihenfolge bestimmen dürfen, gibt es keine Reihenfolge. Alles zu Aufgaben, Anforderungsprofil und den typischen Fehlern in dieser Rolle steht in Product Owner.

Scrum Master

Der Scrum Master verantwortet, dass der Rahmen wirklich gelebt wird — und dass das Team liefern kann. Er räumt Hindernisse weg, moderiert die Termine, schützt das Team vor Zurufen von außen und bringt der Organisation bei, wie sie mit einem selbstorganisierten Team umgeht. Er ist kein Vorgesetzter und kein Sekretär mit Kalenderzugriff. Aufgaben, Abgrenzung und der Weg in die Rolle: Scrum Master.

Die Entwickler

„Entwickler" meint hier jeden, der am Ergebnis arbeitet — im Softwarehaus die Programmiererin, im Maschinenbau der Konstrukteur, in der Agentur die Texterin. Die Entwickler entscheiden selbst, wie sie die Sprint-Aufgaben lösen und wie viel sie sich für einen Sprint vornehmen. Verantwortlich für das Ergebnis sind sie gemeinsam, nicht jeder für sein Teilstück.

Genau hier kippt es in vielen Unternehmen: Die Rollen stehen auf dem Papier, aber die alte Hierarchie entscheidet weiter. Wenn du sauber trennen willst, wer entscheidet und wer nur gehört wird, hilft dir die RACI-Matrix — sie klärt Verantwortlichkeiten für jedes Vorhaben, agil oder nicht.

Die drei Scrum-Artefakte

Ein Team führt drei Arbeitsergebnisse: Product Backlog, Sprint Backlog und Increment. Jedes davon hat seit 2020 eine feste Zusage, ein sogenanntes Commitment. Mehr Dokumente braucht der Rahmen nicht.

Product Backlog

Das Product Backlog ist die einzige gültige Liste aller Aufgaben, die am Produkt noch offen sind. Geordnet, nicht gesammelt: Was oben steht, kommt als Nächstes. Der Product Owner ordnet. Die Liste ist nie fertig — sie wächst und schrumpft, solange das Produkt lebt.

Die Zusage dazu ist das Produktziel. Ein Satz, der beschreibt, wo das Produkt hinsoll. Ohne dieses Ziel wird das Backlog zur Wunschliste, in der alles gleich wichtig ist. Wenn du an dieser Stelle merkst, dass dir übergeordnete Ziele fehlen: OKR ist das Verfahren, mit dem du Unternehmensziele so herunterbrichst, dass Teams damit arbeiten können.

Einzelne Einträge im Backlog werden meist als User Story formuliert — als kurzer Satz aus Sicht des Nutzers plus Akzeptanzkriterien. Das ist die agile Form der Anforderung. Die klassische Form heißt Lastenheft und Pflichtenheft: dort wird vorab vollständig beschrieben, was geliefert werden soll. User Story = agile Anforderung, Lastenheft und Pflichtenheft = klassische Anforderung. Beides hat seine Berechtigung, aber nicht im selben Projekt.

Ordnen ist dabei die eigentliche Arbeit, nicht Sammeln. Eine Liste mit 300 Einträgen, von denen 280 nie umgesetzt werden, kostet dich jede Woche Abstimmungszeit. Streich, was du in einem halben Jahr nicht anfassen wirst. Was oben liegt, ist genau beschrieben; was weiter unten steht, darf grob bleiben — die Genauigkeit wächst, je näher ein Eintrag rückt.

Sprint Backlog

Das Sprint Backlog ist der Plan der Entwickler für den laufenden Sprint: das Sprint-Ziel, die ausgewählten Einträge und der Weg dorthin. Es gehört dem Team, nicht dem Product Owner. Wer von außen etwas hineinlegt, hat den Rahmen verlassen.

Die Zusage dazu ist das Sprint-Ziel — ein einziger Satz, der sagt, wozu dieser Sprint gut ist. Es ist der Grund, warum ein Sprint nicht einfach eine Liste abgearbeiteter Tickets ist.

Increment

Das Increment ist das, was am Ende des Sprints tatsächlich benutzbar ist. Nicht „fast fertig". Nicht „muss noch getestet werden". Benutzbar. Jeder Sprint erzeugt mindestens eines.

Die Zusage dazu ist die Definition of Done — die gemeinsame Definition davon, wann etwas fertig ist. Im Mittelstand ist das der unterschätzteste Teil des ganzen Rahmens. Solange „fertig" für jeden etwas anderes bedeutet, misst du nichts, sondern schätzt Stimmungen. Dieselbe Logik gilt für dein Tagesgeschäft: Klare Übergabepunkte sind der Kern von sauberem Prozessmanagement.

Die fünf Scrum-Events

Scrum kennt fünf Termine: den Sprint selbst und darin Sprint Planning, Daily Scrum, Sprint Review und Sprint Retrospektive. Alle haben eine feste Obergrenze für die Dauer. Alle finden statt — auch wenn es gerade eng ist.

Der Sprint

Der Sprint ist der Behälter für alles andere. Maximal ein Monat, in der Praxis meist zwei Wochen. Er startet unmittelbar, wenn der vorherige endet. Während eines Sprints wird das Sprint-Ziel nicht verändert und die Qualität nicht gesenkt. Abgebrochen werden darf ein Sprint nur vom Product Owner — und nur, wenn das Sprint-Ziel wertlos geworden ist. Das kommt selten vor. Wenn es bei dir monatlich vorkommt, ist nicht der Sprint das Problem, sondern deine Strategie.

Sprint Planning

Das Sprint Planning eröffnet den Sprint und beantwortet drei Fragen: Warum ist dieser Sprint wertvoll? Was kann geliefert werden? Wie wird das gemacht? Obergrenze: acht Stunden bei einem Monatssprint, entsprechend weniger bei kürzeren.

Der Product Owner bringt das Produktziel und die geordneten Einträge mit. Die Entwickler wählen aus, was sie sich zutrauen — sie, nicht der Chef. Und das Team formuliert gemeinsam das Sprint-Ziel. Zwei Fehler kosten hier am meisten: unvorbereitet reingehen (dann diskutiert ihr acht Stunden über Anforderungen statt über den Plan) und das Team überbuchen (dann ist am Ende nichts fertig, statt weniger fertig).

Daily Scrum

Das Daily Scrum ist der 15-Minuten-Termin der Entwickler, jeden Arbeitstag, gleiche Zeit, gleicher Ort. Zweck: den Fortschritt zum Sprint-Ziel prüfen und den Plan für die nächsten 24 Stunden anpassen. Fertig.

Es ist ausdrücklich kein Statusbericht an den Chef. Sobald der Geschäftsführer dort sitzt und Fragen stellt, berichten die Leute nach oben statt sich untereinander abzustimmen — und der Termin ist tot. Wenn du Statusinformationen brauchst, hol sie dir aus dem Sprint Review. Diskussionen, die länger dauern, werden notiert und danach im kleinen Kreis geführt.

Sprint Review

Im Sprint Review zeigt das Team das Increment und holt Rückmeldung von allen, die betroffen sind: Kunden, Vertrieb, Geschäftsführung. Obergrenze vier Stunden beim Monatssprint. Anschließend wird das Product Backlog angepasst.

Das ist ein Arbeitstermin, keine Präsentation. Keine Folien — das Ergebnis. Wer hier ehrliche Rückmeldung bekommt, spart sich sechs Monate später eine teure Korrektur.

Lad die Leute ein, die wirklich betroffen sind. Ein Vertriebler, der den Kunden täglich am Telefon hat, findet in zehn Minuten die Lücke, die im Team niemand gesehen hat. Und wenn ein Kunde selbst dabeisitzt, hörst du die Wahrheit ungefiltert — unangenehm, aber billiger als jede Marktforschung.

Sprint Retrospektive

Die Retrospektive schließt den Sprint ab. Das Team schaut auf die eigene Zusammenarbeit: Was lief, was nicht, was ändern wir konkret im nächsten Sprint? Obergrenze drei Stunden. Ergebnis ist mindestens eine Verbesserung, die im nächsten Sprint tatsächlich umgesetzt wird.

Das ist der Termin, den Unternehmen als Erstes streichen — und der wichtigste von allen. Er ist der eingebaute Verbesserungsmotor. Dieselbe Denkweise steckt hinter KVP, dem kontinuierlichen Verbesserungsprozess: kleine Korrekturen in festem Takt schlagen die große Reorganisation alle drei Jahre.

Der Scrum-Ablauf in der Praxis

Der Scrum-Ablauf ist immer gleich: Backlog ordnen, Sprint planen, täglich abstimmen, Ergebnis zeigen, Zusammenarbeit verbessern, nächster Sprint. So sieht ein Zwei-Wochen-Sprint konkret aus.

Montag, Woche eins — Sprint Planning. Zwei bis drei Stunden. Der Product Owner erklärt, worauf es ankommt. Die Entwickler ziehen sich die Einträge, die sie schaffen. Das Sprint-Ziel steht am Ende an der Wand.

Dienstag bis Donnerstag, täglich — Daily Scrum. 15 Minuten, im Stehen. Wer hängt? Wo brauchen wir Hilfe? Kommen wir ans Sprint-Ziel? Der Scrum Master notiert, was blockiert, und räumt es weg.

Mittwoch, Woche zwei — Backlog Refinement. Kein eigenes Event im Regeltext, aber gelebte Praxis: Das Team schaut auf die nächsten Einträge im Product Backlog, klärt Unklarheiten und schätzt grob. Eine Stunde reicht. Ohne das ist das nächste Planning ein Ratespiel.

Freitag, Woche zwei, vormittags — Sprint Review. Das Team zeigt, was fertig ist. Vertrieb und Geschäftsführung reagieren. Rückmeldungen wandern ins Backlog.

Freitag, Woche zwei, nachmittags — Retrospektive. 60 bis 90 Minuten. Eine konkrete Maßnahme wird beschlossen und im nächsten Sprint umgesetzt.

Montag darauf startet der nächste Sprint. Kein Puffer, keine Pause, keine Projektphase dazwischen. Der Takt ist der eigentliche Hebel: Wenn dein Unternehmen alle zwei Wochen zeigt, was fertig ist, verschwinden Statusdiskussionen von allein.

Und du brauchst dafür keine Software. Ein Whiteboard mit drei Spalten und Klebezetteln reicht für die ersten Monate völlig aus — sichtbar für alle, jederzeit. Ein Werkzeug kaufst du erst, wenn das Team verteilt arbeitet oder die Zettelwand unübersichtlich wird. Wer mit der Softwareauswahl anfängt, diskutiert vier Wochen über Lizenzen statt zu liefern.

Wo Scrum trägt — und wo nicht

Scrum trägt dort, wo du am Anfang nicht weißt, wie das Ergebnis genau aussehen muss. Es trägt nicht dort, wo Ablauf und Ergebnis feststehen und nur sauber abgearbeitet werden müssen. Das ist die ganze Entscheidungsregel.

Scrum ist die richtige Wahl, wenn:

• die Anforderungen sich während der Arbeit noch verändern
• Rückmeldung von Kunden oder Markt den Weg beeinflusst
• ein Team von drei bis zehn Leuten gemeinsam an einem Ergebnis arbeitet
• Teilergebnisse schon Nutzen stiften, bevor alles fertig ist
• du bereit bist, Entscheidungsbefugnis wirklich abzugeben

Die falsche Wahl ist es, wenn:

• Ablauf, Termin und Ergebnis vertraglich fixiert sind
• Genehmigungen und Abnahmen den Takt bestimmen, nicht das Team
• die Arbeit auf Einzelpersonen verteilt ist, die nichts miteinander zu tun haben
• es um wiederkehrende Routine geht statt um ein Vorhaben mit Anfang und Ende
• die Führung im Zweifel doch wieder selbst entscheidet

Wichtig ist die ehrliche Einordnung: Die meisten Mittelständler sind ein Mischbetrieb. Die Fertigung läuft nach festen Abläufen, die Produktentwicklung braucht Spielraum. Dann stellst du nicht das ganze Unternehmen um, sondern genau die Einheit, die es braucht. Alles andere ist eine Umstellung ohne Anlass.

Für den letzten Punkt gibt es keine Methode, nur eine Entscheidung. Wenn du Aufgaben nicht abgeben kannst, wird jeder Rahmen zur Kulisse — dazu findest du das Handwerkszeug in Delegieren lernen.

Die fünf häufigsten Scrum-Fehler im Mittelstand

Der häufigste Fehler ist nicht falsche Anwendung, sondern halbe Anwendung: Man nimmt die Begriffe und lässt die Regeln weg.

Erstens: Scrum ohne Product Owner mit Entscheidungsbefugnis. Wenn die Reihenfolge im Backlog jedes Mal beim Geschäftsführer abgesegnet werden muss, ist die Rolle Dekoration. Entweder du gibst die Entscheidung ab oder du lässt es.

Zweitens: Sprints, in die ständig etwas hineingerufen wird. „Nur ganz kurz, der Kunde braucht das heute." Nach drei solchen Einwürfen ist das Sprint-Ziel wertlos und das Team lernt, dass Planung sinnlos ist.

Drittens: keine Definition of Done. Ohne sie ist „fertig" Verhandlungssache. Das Ergebnis sind Sprints, deren Reste sich über Monate stapeln.

Viertens: das Daily Scrum als Kontrolltermin. Sobald es zur Berichterstattung nach oben wird, verschwindet die Selbstorganisation, die den Rahmen erst sinnvoll macht. Wie du Kontrolle durch Klarheit ersetzt, steht in Mitarbeiterführung.

Fünftens: die Retrospektive streichen. Ohne sie wiederholt ihr jeden Sprint dieselben Fehler in schnellerem Takt. Das ist keine Beschleunigung, das ist Lärm.

Was bei fast allen fünf Punkten mitschwingt: Scrum verändert, wer im Unternehmen entscheidet. Das ist eine Veränderung der Organisation, kein Termin-Umbau — und sie will begleitet werden. Der Rahmen dafür steht in Change Management.

Neben Scrum: die anderen Werkzeuge im Projektmanagement

Scrum ist ein Werkzeug, nicht das Werkzeug. Für jedes angrenzende Thema haben wir einen eigenen Artikel — hier steht, welcher welche Frage beantwortet:

• Agiles Projektmanagement — der Überblick über die ganze Methodenfamilie: Scrum, Kanban, Scrumban, Lean, Extreme Programming und was agiles Arbeiten im Mittelstand praktisch bedeutet.
• Kanban — der Fluss-Ansatz ohne feste Sprints: Board, Spalten, WIP-Limits. Die richtige Wahl, wenn Arbeit laufend hereinkommt statt in Paketen.
• Wasserfallmodell — das klassische Phasenmodell mit fester Reihenfolge. Woher es kommt, wo es bis heute die bessere Wahl ist und wo es Projekte reihenweise gegen die Wand fährt.
• Gantt-Diagramm — die Zeitachse deines Projekts: Balken, Abhängigkeiten, Meilensteine. Beantwortet die Frage „wann".
• Projektstrukturplan — die Zerlegung des Projekts in Arbeitspakete. Beantwortet die Frage „was". Merksatz für beide: Projektstrukturplan ist Struktur und Was, Gantt-Diagramm ist Zeit und Wann.
• Lastenheft und Pflichtenheft — die klassische Anforderungsdokumentation: Wer schreibt was, worin liegt der Unterschied, und welche Formulierungen dich vor Streit mit dem Dienstleister schützen.
• User Story — die agile Anforderung in einem Satz, inklusive Akzeptanzkriterien und der Frage, wie klein eine Story sein muss.
• Product Owner — die Rolle, die über Reihenfolge und Wert entscheidet: Aufgaben, Backlog-Arbeit, Zusammenspiel mit Vertrieb und Geschäftsführung.
• Scrum Master — die Rolle, die den Rahmen hält: Aufgaben, Abgrenzung zur Führungskraft, Zertifizierungen und was sie taugen.

Und darüber steht der Feld-Anker: Projektmanagement beantwortet die Frage, wie du Projekte überhaupt neben dem Tagesgeschäft lieferst — unabhängig davon, ob du dabei agil oder klassisch arbeitest. Wenn dein eigentliches Problem nicht die Methode ist, sondern die Zeit, fängst du besser bei Zeitmanagement an.

So startest du mit Scrum in 30 Tagen

Du brauchst weder Zertifikat noch Software, um anzufangen. Du brauchst ein Team, ein Ziel und zwei Wochen.

Nimm ein einziges Vorhaben, das wirklich unklar ist. Setz ein Team von drei bis sieben Leuten darauf. Bestimme einen Product Owner, der entscheiden darf — schriftlich, damit es niemand später anders erinnert. Bestimme einen Scrum Master, notfalls in Teilzeit. Schreib die zehn wichtigsten offenen Punkte untereinander und ordne sie. Definiert gemeinsam in einem Satz, was „fertig" heißt.

Dann startet ihr den ersten Sprint: zwei Wochen, ein Ziel, tägliche Abstimmung, am Ende Review und Retrospektive. Der erste Sprint wird nicht gut. Der dritte schon. Und ab dem sechsten willst du nicht mehr anders arbeiten.

Und dann kommt der Punkt, an dem die Methode aufhört und die Führung anfängt. Ich habe in 35 Jahren Vertrieb kein einziges Unternehmen gesehen, das an der Methodik gescheitert ist — sie scheitern daran, dass der Unternehmer nicht loslässt. Genau dafür habe ich die sieben Anleitungen zusammengestellt, mit denen meine Mentoring-Kunden ihre Firma vom Tagesgeschäft entkoppeln: Entscheidungen abgeben, Verantwortung verteilen, Ergebnisse messbar machen. Hol dir das Unternehmer-Paket und fang mit der Anleitung an, die zu deiner nächsten Baustelle passt.

Häufige Fragen zu Scrum

Wie lange dauert ein Sprint?

Höchstens einen Monat. In der Praxis haben sich zwei Wochen durchgesetzt, weil das lang genug für ein echtes Ergebnis und kurz genug für schnelle Korrektur ist. Wichtig ist die Konstanz: Wenn die Länge ständig wechselt, verliert das Team jedes Gefühl dafür, was in einen Sprint passt. Leg dich fest und bleib mindestens sechs Sprints dabei, bevor du änderst. Kürzere Zyklen bedeuten mehr Termine, aber auch schnellere Korrektur — bei hoher Unsicherheit ist das der bessere Tausch.

Braucht man für Scrum eine Zertifizierung?

Nein. Der offizielle Regeltext ist frei verfügbar und in unter einer Stunde gelesen. Eine Zertifizierung ist ein strukturierter Einstieg und im Lebenslauf ein Signal — sie ersetzt aber keine Praxis. Wenn du im Mittelstand startest, investierst du das Geld besser in eine erfahrene Begleitung für die ersten drei Sprints als in Prüfungsgebühren. Details zu Anbietern, Formaten und Kosten stehen im verlinkten Rollenartikel.

Was ist der Unterschied zwischen Scrum und Kanban?

Scrum arbeitet in festen Zyklen mit festem Umfang: Am Sprintbeginn wird ausgewählt, danach bleibt der Umfang stabil. Kanban arbeitet im Fluss: Aufgaben kommen laufend herein, begrenzt wird nicht die Zeit, sondern die Anzahl gleichzeitig laufender Aufgaben. Scrum passt zu Vorhaben mit Ziel, Kanban zu laufendem Betrieb wie Support oder Wartung. Die ausführliche Gegenüberstellung findest du im Kanban-Artikel.

Funktioniert Scrum auch außerhalb der IT?

Ja — überall dort, wo ein Team gemeinsam an etwas Unklarem arbeitet. Marketing-Teams planen Kampagnen in Sprints, Personalabteilungen bauen damit Recruiting-Prozesse um, Maschinenbauer entwickeln Baugruppen. Die Begriffe stammen aus der Softwareentwicklung, das Prinzip nicht. Was du brauchst, ist ein Ergebnis, das sich alle zwei Wochen zeigen lässt. Wo das nicht geht, ist Scrum die falsche Wahl.

Wie viele Leute gehören in ein Scrum-Team?

Zehn oder weniger, inklusive Product Owner und Scrum Master. Kleiner ist meist besser: Ab etwa acht Personen steigt der Abstimmungsaufwand schneller als die Leistung. Wenn dein Vorhaben größer ist, teilst du es in mehrere Teams mit je eigenem Sprint-Ziel — nicht in ein Team mit 20 Leuten. Wie du Teams so zusammensetzt, dass sie liefern, steht in Teambuilding.

Scrum ist kein Glaubenssystem. Es ist ein Takt, der dein Unternehmen zwingt, alle zwei Wochen zu zeigen, was fertig ist. Wer diesen Takt aushält, braucht keine Statusrunden mehr. Mit System, nicht mit Glück.