Wie funktioniert Scrum?

Welche Events, Rollen, Artefakte gibt es? Wer hat welche Aufgaben und warum ist das agile Mindset so wichtig?

Scrum – Definition

Scrum ist ein agiles Framework für die Entwicklung und Instandhaltung komplexer Produkte und Services. Ursprünglich für die Softwareentwicklung konzipiert, wird Scrum heutzutage in vielen Bereichen und Industrien verwendet. Es definiert mit Sprints, Sprint Planning, Daily Scrum, Sprint Review und Retrospektive fünf Events bzw. Aktivitäten oder Rituale. Es legt mit dem Product Owner, dem Scrum Master und dem Entwicklungsteam drei Rollen fest. Es benennt mit dem Product Backlog, dem Sprint Backlog und Product Inkrement drei Artefakte. Diese Events, Rollen und Artefakte sind der Kern von Scrum. Die Regeln zur Anwendung von Scrum sind im Scrum Guide definiert. Der Ansatz von Scrum ist empirisch, inkrementell und iterativ. Er geht davon aus, dass viele Entwicklungsprojekte zu komplex für eine exakte Planung und Beschreibung sind, da viele Anforderungen und Lösungen zu Projektbeginn unklar sind. Diese Unklarheiten werden durch ein schrittweises Vorgehen und die Entwicklung von potenziell lieferfähigen Inkrementen beseitigt.

Das agile Manifest

Im Jahr 2001 formulierten 14 Autoren, u.a. Ken Schwaber und Jeff Sutherland, das agile Manifest. Es definiert Werte und agile Prinzipien, die in Scrum Anwendung finden:

  • Individuen und Interaktionen sind wichtiger als Prozesse und Werkzeuge
  • Funktionierende Software ist wichtiger als eine umfassende Dokumentation
  • Die Zusammenarbeit mit Kunden ist wichtiger als die Vertragsverhandlung
  • Das Reagieren auf Veränderung ist wichtiger als das Festhalten an Plänen

Diese Werte beinhalten immer zwei Seiten. Die linke Seite ist dabei wertvoller als die rechte. Natürlich darf die rechte Seite nicht zu weit in den Hintergrund rücken; bspw. lassen sich nicht alle Funktionen einer Software ohne Dokumentation nachvollziehen. Bei der Entwicklung von Lösungen ist also immer auch auf eine Ausgewogenheit der Werte zu achten.

Was ist Scrum?
\

Das Framework

Scrum ist ein agiles Framework, das ein Set aus Rollen, Events und Artefakten definiert. Es adressiert ein empirisches, inkrementelles und iteratives Vorgehen.

\

Die Organisation

Zu erledigende Epics, Features, Anforderungen oder User Storys werden in einem Backlog verwaltet. Die Items im Backlog werden priorisiert und kontinuierlich gepflegt.

\

Das Sprint Backlog

Im Sprint Backlog finden sich die User Storys, deren Umsetzung das Entwicklungsteam für den anstehenden Sprint im Sprint Planning zugesagt hat.

\

Der Sprint

Der Sprint in Scrum ist eine Timebox mit einer festen, gleichbleibenden Dauer von 1 bis 4 Wochen. Im Rahmen des Sprints gilt es das vereinbarte Sprintziel zu erreichen und die User Storys des Sprint Backlogs zu realisieren.

\

Das Daily Scrum

Der Sprint in Scrum ist eine Timebox mit einer festen, gleichbleibenden Dauer von 1 bis 4 Wochen. Im Rahmen des Sprints gilt es das vereinbarte Sprintziel zu erreichen und die User Storys des Sprint Backlogs zu realisieren.

\

Das Inkrement

Im Daily Scrum tauschen sich die Entwickler untereinander über die Aufgaben und Hindernisse aus. Auch beim Daily Scrum kommt eine vereinbarte Timebox zur Anwendung.

Vorteile von Scrum

Scrum setzt auf klare Regeln und Abläufe, und fördert die Kommunikation zwischen den Beteiligten. Da Vorhersagen und die Erstellung von realistischen Plänen bei der Entwicklung von Software und Systemen häufig schwierig sind, dreht Scrum den Ansatz um: Wissen entsteht aus Erfahrung und Erfahrung entsteht im Laufe einer Entwicklung. In Verbindung mit dem iterativen Vorgehen, dem Commitment des Teams auf das Sprint-Ziel und dem frühzeitigen Erkennen von Hindernissen, erhöht sich die Vorhersagbarkeit und das Entwicklungsrisiko sinkt. Stakeholder erhalten die Möglichkeit, frühzeitig Feedback zu geben und Verbesserungsvorschläge zu äußern.

Die Flexibilität beim Arbeiten mit Scrum, die konzentrierte Kommunikation zwischen den Scrum Rollen, das Feedback, die Transparenz der Arbeitsschritte und Zwischenergebnisse, die Fähigkeit, Abweichungen zu erkennen und zu korrigieren, sowie die Möglichkeit, den Prozess im laufenden Projekt zu justieren, sind die größten Vorteile von Scrum.

Verschiedene Events in der Praxis

Sprint Planning

Zu Beginn eines Sprints findet das Sprint Planning statt. Es ist ein Treffen zur Planung der Anforderungen und Arbeitspakete, die im aktuellen Sprint umgesetzt werden sollen. Die Teilnahme ist für die Entwickler  verpflichtend. Organisiert wird das Meeting vom Product Owner, moderiert vom Scrum Master. Das Sprint Planning teilt sich in zwei Phasen auf:  Beim Sprint Planning 1 wird über das „Was“ gesprochen, also was soll im nächsten Sprint realisiert werden. Ein Sprint-Ziel wird vereinbart und die Entwickler verpflichten sich, die vereinbarten Anforderungen im nächsten Sprint umzusetzen. Beim Sprint Planning 2 einigen sich die Entwickler auf das „Wie“, also wie das Team die Anforderungen realisieren wird. Dazu definieren Sie Tasks und visualisieren diese mit einem Taskboard. Am Ende von Phase 2 sollte das Team in der Lage sein, dem Product Owner und dem Scrum Master zu erklären, wie er als selbstorganisierendes Team arbeiten will, um das Sprint-Ziel zu erreichen und das erwartete Inkrement zu erstellen.

Sprint

Ein Leitmotiv von Scrum ist die Entwicklung von Produkten in kurzen Zyklen bzw. Inkrementen. Diese kurzen Zyklen werden Sprint genannt. Sie sind das Herz von Scrum. Wichtig ist, dass Sprints im gesamten Entwicklungsablauf eine konsistente Dauer haben. Beim Arbeiten mit parallelen Teams sollten Organisationen darauf achten, dass Sprints synchron verlaufen, so dass es nicht zu unnötigen Wartezeiten zwischen den Teams kommt. Während eines Sprints gilt es Änderungen zu vermeiden, um das vom Team verabschiedete Sprint-Ziel gemeinsam zu erreichen und ein potenziell lieferfähiges Inkrement zu entwickeln, also eine Lösung, die funktioniert und Kunden zur Verfügung gestellt werden könnte. Werden einzelne User Storys nicht umgesetzt, so wird der Sprint nicht verlängert, sondern die entsprechenden User Storys gegebenenfalls für einen der nächsten Sprints eingeplant. Die Anpassung von Qualitätszielen und Akzeptanzkriterien ist nicht vorgesehen, sollte jedoch das Sprint-Ziel obsolet werden, kann der Product Owner einen Sprint auch abbrechen.

Daily Scrum

Das Daily Scrum ist ein täglich stattfindendes Meeting, zu dem sich das Entwicklungsteam trifft, um sich gegenseitig über den Fortschritt, die anstehenden Tätigkeiten und mögliche Probleme auszutauschen. Da sich die Teilnehmer im Kreis zum Dialog hinstellen, wird es auch als Standup Meeting oder als daily stand-up bezeichnet. Die Teilnahme an dem Meeting ist für das Entwicklungsteam verpflichtend, zusätzlich sollte der Scrum Master und könnte der Product Owner teilnehmen. Beim Daily Scrum soll jedes Teammitglied drei Fragen beantworten: Was habe ich seit gestern getan? Was mache ich bis morgen? Was behindert mich bei meiner Arbeit? Durch den Austausch untereinander synchronisiert sich das Team und Redundanzen werden vermieden. Wichtig ist dabei, dass die Teilnehmer sich bei der Beantwortung der Fragen am Sprint-Ziel orientieren.

Sprint Review

Das Sprint Review ist ein Treffen am Ende eines Sprints zur Beurteilung und Abnahme der erledigten Arbeit in Bezug auf das gesteckte Sprint-Ziel. Am Sprint Review nehmen das gesamte Entwicklungsteam – also die Entwickler, der Scrum Master und der Product Owner – und idealerweise ausgewählte Stakeholder – also bspw. Anwender, Manager, Vertreter aus Bereichen wie Marketing, Vertrieb oder IT – teil.  Beim Sprint Review wird sichtbar, was im Sprint erarbeitet wurde und welche User Storys freigegeben werden. Da nur realisierte User Storys und deren Umsetzung live im Produkt präsentiert werden dürfen, ist der Fortschritt der Entwicklung für alle Beteiligten direkt ersichtlich. Durch die Teilnahme von Stakeholdern können diese direktes Feedback und somit Kritik, Lob und Verbesserungsvorschläge äußern, die gegebenenfalls vom Product Owner für den nächsten Sprint eingeplant werden.

Retrospektive

Eine Retrospektive ein regelmäßiges Treffen, zu dem sich das Entwicklungsteam trifft, um die jüngere Vergangenheit – also den zurückliegenden Sprint – zu beleuchten und dadurch die zukünftige Zusammenarbeit im Team zu verbessern. Es ist ein Meeting, bei dem Prozesse, Werkzeuge, Fähigkeiten, Beziehungen, Herausforderungen und Erfahrungen reflektiert werden. Das Feedback bietet dabei Chancen sowohl für das Team als Ganzes als auch für jeden einzelnen Teilnehmer. Ziele sind die Verbesserung der Zusammenarbeit im Team und somit die Verbesserung von Abläufen und Inhalten, sowie die Festlegung von Maßnahmen, von Dos und Don’ts, basierend auf  den gemeinsam gewonnen Erkenntnissen. Darüber hinaus bietet die Retrospektive Raum für offenes Feedback im Team und zur Überprüfung der vereinbarten Maßnahmen der vergangenen Retrospektive.

Scrum of Scrums

Das Scrum of Scrums bezeichnet ein regelmäßiges Treffen von Vertretern einzelner Scrum-Teams. Es dient dem Zweck, sich gegenseitig über den Status quo der einzelnen Teams, über anstehende Tätigkeiten und mögliche Hindernisse bei der Entwicklung auszutauschen. Im engeren Sinne gilt das Scrum of Scrums nicht als Scrum Event. Ziel ist es, die Arbeit der verschiedenen Scrum-Teams zu synchronisieren und Entwicklungen zu identifizieren, die andere Teams bei der Umsetzung ihrer Anforderungen beeinflussen. Jeder Vertreter eines Scrum-Teams beantwortet dafür vier Fragen: Was hat mein Team geschafft, seit wir uns das letzte Mal getroffen haben? Was wird mein Team bis zum nächsten Treffen erledigen? Welche Hindernisse behindern mein Team bei der Arbeit? Könnte eine Tätigkeit meines Teams ein anderes Team beeinflussen oder behindern?

Scrum Whitepaper - t2informatik Download Vorschau

Jetzt das Scrum Whitepaper kostenlos downloaden.

Alles Wichtige über Scrum, die zentralen Begriffe, Rollen, Events und Herausforderungen auf 29 Seiten zum Mitnehmen.

Hier klicken »

Verschiedene Scrum Rollen in der Praxis

Product Owner

Der Product Owner ist neben dem Scrum Master und dem Entwicklungsteam eine der drei zentralen Rollen in Scrum. Er repräsentiert die Vorstellungen der Stakeholder, erstellt und pflegt das Product Backlog, und arbeitet eng mit dem Entwicklungsteam zusammen. Er legt das Projektziel fest und ist für den Erfolg der Entwicklung verantwortlich. Er steuert die Entwicklung über die Formulierung und Priorisierung von Epics, Features, Anforderungen und User Storys. Er verantwortet die Releases und Releasepläne, pflegt einen Kazapitätsplan und betreibt Risikomanagement. Er vereint somit Produkt- und Projektmanagementaufgaben. Trotz seiner Verantwortung und seinen zahlreichen Aufgaben ist er aber nicht der Vorgesetzte des Entwicklungsteams. Er sollte sich weder in technische Lösungsdiskussionen oder die Schätzung von Aufwänden einmischen. Damit der Product Owner seine Rolle gut ausführen kann, muss er vom Management bevollmächtigt sein, um bspw. Entscheidungen bzgl. Anforderungen und Funktionsumfang treffen zu können. Darüber hinaus ist es wichtig, dass er sowohl fachlich als auch kommunikativ qualifiziert und stets verfügbar ist.

Scrum Master

Der Scrum Master trägt die Verantwortung für die Einhaltung des Scrum-Prozesses und dessen Implementierung im Unternehmen. Er moderiert die Scrum-Meetings, sorgt für die Einhaltung der vereinbarten Timebox, erfasst und beseitigt Hindernisse (die sogenannten Impediments) und schützt das Team vor unberechtigten Eingriffen während der Entwicklung. Er fördert die Kommunikation zwischen Entwicklungsteam und Product Owner und behält dabei verschiedene Artefakte wie das Product und Sprint Backlog, Burndown Charts, Taskboards oder das User Story Mapping im Auge. Im Rahmen der Retrospektive versucht er die Zusammenarbeit im und mit dem Team, sowie die gelebten Prozesse zu verbessern. Dort hat er auch Gelegenheit, Feedback zu seiner eigenen Tätigkeit zu erfragen. In seiner Rolle ist ein Scrum Master gleichzeitig Coach, Moderator und Vermittler. Seine Rolle sollte aber nicht mit einem Projektleiter verwechselt werden, denn das Entwicklungsteam organisiert sich selbst und kommuniziert auch direkt mit dem Product Owner. Eine Doppelfunktion als Product Owner oder Teammitglied sollte auf jeden Fall vermieden werden.

Entwicklungsteam

Ein Entwicklungsteam in Scrum besteht aus 3 bis 9 Personen. Idealerweise werden Entwicklungsteams funktionsübergreifend zusammengestellt, so dass sie gemeinsam alle erforderlichen Fähigkeiten besitzen, um ein Inkrement am Ende des Sprints zu erstellen. Dabei muss das Team vor allem in der Lage sein, Architekturen zu entwerfen oder zu optimieren, sowie Software zu entwickeln und zu testen. Unabhängig von den Fähigkeiten der einzelnen Mitglieder definiert Scrum keine zusätzlichen Rollen oder Titel für Teammitglieder. Damit betont Scrum die gemeinsame Verantwortung des Teams, ein potenziell lieferbares Inkrement zu liefern. Grundsätzlich gilt, dass Entwicklungsteams selbstorganisierend sind. Weder der Product Owner noch der Scrum Master sind dem Team vorgesetzt. Damit wird die Kommunikation im Zuge der verschiedenen Scrum Events um so wichtiger.

Stakeholder

In Scrum haben Stakeholder keine explizite Rolle, nehmen aber an verschiedenen Stellen maßgeblich Einfluss auf die Entwicklung. Mit Ihren Zielen liefern sie oft eine Grundlage für Anforderungen. Der Product Owner stimmt sich bspw. mit wesentlichen Stakeholdern ab und vertritt ihre Meinungen bspw. im Sprint Planning. Wer die Aufgaben der Stakeholderidentifikation und Stakeholderanalyse übernimmt, entscheiden Organisationen individuell. Am Sprint Planning 1 dürfen sie – sofern es Sinn macht und sie Interesse am Gelingen des Vorhabens haben – als Ansprechpartner für die Entwickler teilnehmen. Beim Sprint Review dürfen sie aktiv mitwirken und Feedback zu den umgesetzten User Storys sowie Verbesserungsvorschläge äußern. Bei weiteren Scrum Events wie bspw. dem Daily Scrum dürfen sie auf Einladung als stille Beobachter teilnehmen. 

Verschiedene Konzepte in der Praxis

Timeboxing in Scrum

Timeboxing ist eine zentrale Technik in Scrum. Sie ist Bestandteil sowohl beim Sprint Planning, als auch im Sprint selbst, sie findet Anwendung bei den Daily Scrums, dem Sprint Review und der Sprint Retrospektive. Es gibt sogar Organisationen, da wird Timeboxing nicht nur für Sprints, sondern sogar innerhalb einzelner Sprints verwendet, bspw. zur Beseitigung von Unklarheiten, zur Durchführung von Recherchen oder beim Arbeiten mit Spike Storys. Ein wesentlicher Gedanke beim Timeboxing ist die klare Definition of Done, durch die Inhalte, die nicht allen Akzeptanz- und Fertigstellungskriterien entsprechen, in zukünftigen Timeboxes behandelt werden. Die sinnvolle Bestimmung der Dauer einer Timebox ist besonders wichtig. Hier empfiehlt es sich, gemeinsam im Team eine zur Organisation, zur Arbeitsweise und zum Projektgegenstand passende Dauer festzulegen. Für die Einhaltung der Timebox ist der Scrum Master verantwortlich.

Definition of Done

Die Definition of Done ist eine Checkliste mit Qualitätskriterien, die beschreibt, welche Kriterien erfüllt sein müssen, damit die Erstellung eines Produkts als erledigt betrachtet werden kann. Da Menschen unterschiedliche Vorstellungen von Qualität haben, ist es wichtig, sich gemeinsam im Team auf eine Definition of Done festzulegen. Damit liegt die Verantwortung für die Definition of Done auch beim Team und sie wirkt als Selbstverpflichtung für das Team. Mit einer Definition of Done wird Klarheit erzeugt, denn durch sie wissen alle Beteiligten stets, was benötigt wird, damit etwas als „fertig“ gelten kann. Diese Klarheit hängt nicht von persönlichen Einschätzungen ab; sie ist das Ergebnis von vereinbarten Kriterien, die allesamt erfüllt sein müssen, so dass aus einem „fast fertig“ ein „fertig“ bzw. „done“ wird. Darüber hinaus steht eine Definition of Done für einen Qualitätsanspruch, für eine Aussrichtung auf Werte und Prozeduren.

User Storys

Der Begriff „User Story“ setzt sich aus dem Wort user, also  Anwender oder Benutzer, und story, also Geschichte, zusammen. Im wörtlichen Sinne beschreibt eine User Story also eine Geschichte eines Anwenders. In Scrum ist eine User Story ein Werkzeug, um gewünschte Funktionalitäten eines System aus Sicht des Anwenders zu beschreiben. Dabei bietet eine User Story vor allem drei Vorteile:

  • sie ist leicht zu verstehen und vermittelt die Wünsche der Anwender
  • sie ist schnell erstellt und erleichtert die Schätzung des Aufwands zur Realisierung
  • sie lässt sich schrittweise detaillieren und unterstützt so die iterative Entwicklung

Bei einer User Story geht es vor allem um WerWas und Warum, also wer möchte was von einem System, um welchen Nutzen davon zu haben. Wie die gewünschte Funktionalität später umgesetzt wird, ist für eine User Story unerheblich. Beim Schreiben einer User Story empfiehlt sich folgende Satzstruktur: Als (Rolle) möchte ich (Funktionalität), um (Nutzen) zu erreichen.

Backlogs

Die Verwaltung von Informationen in Backlogs ist in Scrum sehr populär. Ein Backlog ist eine Sammlung von Dingen, insbesondere unvollständiger Arbeit oder Angelegenheiten, die erledigt werden müssen. Oder einfach ausgedrückt: Ein Backlog ist eine Liste von Aufgaben bzw. Anforderungen, die abgearbeitet bzw. realisiert werden sollen. Obwohl Scrum die Verwendung von Product Backlog und Sprint Backlog (neben dem Product Inkrement) als Artefakte definiert, ist die Organisation von Backlogs in Unternehmen unterschiedlich organisiert. So finden sich häufig  Release Backlogs und Team Backlogs. Beim Sprint Planning 1 definiert der Product Owner sein Selected Backlog als Wunschliste – die abgestimmten User Storys wandern anschließend in das Sprint Backlog oder werden entsprechend referenziert. Der Scrum Master pflegt in einem Impediment Backlog die Hindernisse, die im Zuge der Daily Scrums kommuniziert wurden. Darüber hinaus können Entwickler bzw. Mitarbeiter auch persönliche Backlogs pflegen. Generell ist die Pflege und Priorisierung der Backlog Items eine wichtige und kontinuierliche Aufgabe.

Wollen Sie mehr über Scrum erfahren?

Dann erfahren Sie hier mehr über ScrumButs, Tipps und Tricks bei Impediments, den Sinn von Spike Storys oder die Verwendung von Story Points.

Herausforderungen für Unternehmen

Das agile Mindset

Die Anzahl der Organisationen, die Scrum nutzen, wächst kontinuierlich. Unternehmen erhoffen sich mehr Flexibilität, schnellere Entwicklungszyklen oder niedrigere Kosten. Durch die Sprints, die Kommunikation zwischen Product Owner und Stakeholder und das gemeinsame Sprint Planning lässt sich die Flexibilität häufig steigern. Doch diese Flexibilität ist nicht kostenlos. Scrum erfordert regelmäßige Kommunikation zwischen den Beteiligten in Form von Daily Scrums, Sprint Plannings, Sprint Reviews, Retrospektiven und gegebenenfalls Scrum of Scrums. Hinzu kommt der Aufwand, Backlogs zu pflegen, Arbeitspakete zu definieren, Aufwände zu schätzen und den Fortschritt zu dokumentieren. In anderen Worten: Scrum ist keine Abkürzung zu Unternehmenserfolg. Technische Herausforderungen bleiben bestehen, sie lassen sich aber vermutlich im Laufe einer Entwicklung mit neuem Wissen besser beurteilen als zu Projektbeginn. Damit sinkt das Risiko falscher Projektpläne und Versprechungen. Damit dies funktioniert, müssen Organisationen aber nicht nur lernen, die Regeln von Scrum anzuwenden, und die Rollen mit geeigneten Mitarbeitern zu besetzen. Es ist notwendig, ein agiles Mindset zu entwickeln. Das Management muss sich von einem Command and Control – Führungsstil lösen. Das Team muss lernen mit Verantwortung umzugehen und sie bewusst in Anspruch zu nehmen. Der Product Owner muss verstehen, dass er nicht der Vorgesetzte des Entwicklungsteams ist. Und der Scrum Master darf sich nicht als Projektleiter verstehen. Erst mit einem solchen agilen Mindset entfaltet Scrum die größten Vorteile.

Gerne stellen wir Ihnen Wissen, Erfahrung und 100% Leidenschaft für Ihre Softwareentwicklung und Anforderungsanalyse zur Verfügung. Wir helfen Ihnen bei der Erhebung, Strukturierung und Verwaltung von Anforderungen und achten dabei auf Konsistenz, Vollständigkeit und Nachvollziehbarkeit. Wir stellen Ihnen ein agiles Projektteam aus sehr guten Softwarearchitekten und Softwareentwicklern zur Verfügung, das Ihre Anforderungen in kurzen Iterationen in enger Abstimmung mit Ihnen umsetzt. Unser Vorgehen basiert auf den agilen Methoden Scrum und Kanban und vereint diese mit den technischen Praktiken aus Extreme Programming (XP).

Hier erfahren Sie mehr zum Thema Softwareentwicklung »

Weitere Details und Hintergründe ...
Share This