Close

Scrum

Nutze die Stärken von Scrum mit unseren Profitipps

Themen durchsuchen

Was ist Scrum?

Scrum ist ein Framework, das die Zusammenarbeit in Teams unterstützt. "Scrum" steht im Rugby für "Gedränge" – und genau wie ein Rugbyteam, das für das große Spiel trainiert, sind Teams mit Scrum in der Lage, aus Erfahrungen zu lernen, sich bei der Problembehebung selbst zu organisieren sowie ihre Erfolge und Niederlagen zu reflektieren, um sich kontinuierlich zu verbessern.

Scrum wird meist von Softwareentwicklern genutzt, doch das Prinzip und die gewonnenen Erkenntnisse sind für alle Arten von Teamwork hilfreich. Unter anderem aus diesem Grund ist Scrum so beliebt. Scrum wird oft als ein agiles Projektmanagement-Framework beschrieben und umfasst Meetings, Tools und Rollen, die gemeinsam das Strukturieren und Managen der Teamarbeit unterstützen.

In diesem Artikel erklären wir dir mithilfe des Scrum Guide und David West, CEO von Scrum.org., wie ein klassisches Scrum-Framework aufgebaut ist. Außerdem stellen wir Beispiele vor, in denen unsere Kunden von diesem Standard abweichen, um die Lösung ganz ihren eigenen Anforderungen anzupassen. Dazu wird uns Megan Cook von Atlassian, Group Product Manager für Jira Software und früher Agile Coach, in unserer Agile Coach-Videoreihe ihre Tipps und Tricks verraten:

Artikel zu Scrum

[FORTSETZUNG]

Das Framework

Viele denken, Scrum und Agile seien dasselbe, da sich bei Scrum alles um kontinuierliche Verbesserungen dreht – eines der Kernprinzipien von Agile. Jedoch handelt es sich bei Scrum um ein Framework zur Bewältigung von Aufgaben, während Agile eine Denkweise beschreibt. Man kann als Einzelner nicht wirklich "agil werden". Das Engagement des gesamten Teams ist nötig, um einen neuen Denkansatz zur Wertschöpfung für den Kunden zu finden. Ein Framework wie Scrum kann euch dabei helfen, diese neue Denkweise zu verfolgen und die tägliche Kommunikation sowie alltägliche Aufgaben auf agile Grundsätze auszurichten.

Scrum ist ein heuristisches Framework, denn es basiert auf kontinuierlichem Lernen und einer stetigen Anpassung an sich ändernde Faktoren. Es berücksichtigt, dass Teams zu Beginn eines Projekts noch nicht alles wissen können und sich erst durch Erfahrung weiterentwickeln. Scrum ist so aufgebaut, dass sich Teams neuen Bedingungen und Benutzeranforderungen ganz von selbst anpassen können. Durch den flexiblen Prozess, der das Festlegen neuer Prioritäten erlaubt, sowie kurze Release-Zyklen können Teams fortlaufend dazulernen und sich verbessern.

Das Scrum-Framework | Atlassian Agile Coach

Scrum gibt zwar eine Struktur vor, ist jedoch kein völlig starres System. So kann die konkrete Umsetzung des Frameworks an die individuellen Anforderungen eines Unternehmens angepasst werden. Es gibt viele Theorien darüber, welche konkreten Arbeitsweisen Scrum-Teams zum Erfolg führen. Atlassian unterstützt agile Teams nun seit mehr als zehn Jahren bei der Bewältigung ihrer Aufgaben und wir haben die Erfahrung gemacht, dass eine klare Kommunikation, Transparenz sowie eine Hingabe für kontinuierliche Verbesserung stets im Mittelpunkt stehen sollten, gleich welches Framework ihr nutzt. Alles andere bleibt euch überlassen.

Scrum-Artefakte

Beginnen wir mit den drei Artefakten in Scrum. Artefakte werden von uns erstellt, wie ein Tool zum Lösen eines Problems. Diese drei Artefakte in Scrum sind das Produkt-Backlog, das Sprint-Backlog und ein Inkrement, dessen Ziel ihr selbst bestimmt. Es gibt 3 Bezugspunkte, auf die ein Scrum-Team immer wieder zurückkommt und an denen es im Laufe der Zeit arbeitet.

  • Das Produkt-Backlog ist die Master-Liste mit den zu erledigenden Aufgaben. Sie wird vom Produktinhaber oder Produktmanager verwaltet. Diese dynamische Liste an Features, Anforderungen, Verbesserungen und Fehlerbehebungen fließt in das Sprint-Backlog ein. Das ist im Grunde genommen die "To-do-Liste" des Teams. Auf das Produkt-Backlog wird fortlaufend zurückgegriffen, und es wird ständig neu priorisiert. Die Verwaltung übernimmt der Produktinhaber, denn wenn wir Erkenntnisse gewinnen oder sich der Markt verändert, sind manche Aufgabenelemente möglicherweise nicht mehr relevant, oder Probleme lassen sich auf andere Weise lösen.
  • Unter dem Sprint-Backlog versteht man eine Liste an Elementen, User Storys oder Fehlerbehebungen, die ein Entwicklerteam zur Implementierung im aktuellen Sprint-Zyklus auswählt. Vor jedem Sprint entscheidet das Team im Sprint-Planungsmeeting (auf das wir später eingehen), welche Elemente aus dem Produkt-Backlog in einem Sprint bearbeitet werden sollen. Ein Sprint-Backlog kann flexibel sein und sich während eines Sprints weiterentwickeln. Das grundlegende Sprint-Ziel jedoch – d. h., was das Team mit dem aktuellen Sprint erreichen will – muss erfüllt werden.
  • Ein Inkrement (oder Sprint-Ziel) ist das nutzbare Endprodukt, das aus einem Sprint hervorgeht. Wir bei Atlassian präsentieren das "Inkrement" normalerweise bei einer Demo am Sprint-Ende, in der das Team zeigt, was es in dem Sprint zustande gebracht hat. Vielleicht habt ihr das Wort "Inkrement" noch nie gehört. Damit gemeint sind oft die Aufgaben, die ein Team erledigen will, ein Meilenstein, ein Sprint-Ziel oder gar eine Vollversion oder ein ausgeliefertes Epic. Das hängt ganz davon ab, was ein Team erreichen möchte und welche Sprint-Ziele es festgesetzt hat. Beispielsweise beschließen manche Teams, ihren Kunden am Ende jedes Sprints ein Release bereitzustellen. Ihr angestrebtes Ziel lautet also "ausliefern". Für andere Teams ist dieses Ziel vielleicht unrealistisch. Nehmen wir an, ihr arbeitet an einem serverbasierten Produkt, das ihr nur einmal im Quartal an den Kunden ausliefern könnt. Trotzdem könnt ihr zweiwöchige Sprints festlegen und es euch zum Ziel setzen, bereits einen Teil der Version, die ihr am Schluss als Ganzes ausliefern wollt, abzuschließen. Doch je länger ein Software-Release dauert, umso höher ist das Risiko, dass die Software misslingt.

Wie ihr seht gibt es viele Varianten, selbst bei den Artefakten, die euer Team für sich bestimmen kann. Daher ist es wichtig, offen zu bleiben für die Entwicklung neuer Wege, auch die zur Handhabung eurer Artefakte. Vielleicht habt ihr euch ein Ziel gesetzt, das für euer Team stressige Korrekturarbeiten mit sich bringt. Dann müsst ihr einen Schritt zurückgehen und euer Ziel neu definieren.

Profitipp

Ihr solltet mit eurem Framework so flexibel umgehen wie auch mit dem Produkt. Nehmt euch die nötige Zeit für Überprüfungen und falls nötig auch für Anpassungen. Erzwingt nichts, nur um Konsistenz zu wahren.

Scrum-Zeremonien oder -Ereignisse

Zu den bekannteren Komponenten des Scrum-Frameworks gehören eine Reihe von aufeinanderfolgenden Ereignissen, Zeremonien oder Meetings, die Scrum-Teams regelmäßig durchführen. Wir beobachten große Unterschiede zwischen den Zeremonien verschiedener Teams. Zum Beispiel finden manche Teams diese Zeremonien mühsam und monoton, während andere Teams Zeremonien als notwendige Überprüfung nutzen. Wir empfehlen euch, zunächst zwei Sprints lang alle Zeremonien durchzugehen und erst danach zu entscheiden, was ihr übernehmt. Ihr könnt dann eine kurze Retrospektive durchführen, um herauszufinden, was ihr anpassen müsst.

 

Wir stellen euch die wichtigsten Zeremonien vor, die Scrum-Teams nutzen können:

  1. Organisation des Backlogs: Für dieses Ereignis, das auch Backlog-Grooming genannt wird, ist der Produktinhaber verantwortlich. Der Produktinhaber muss vor allem dafür sorgen, dass sich das Produkt der Produktvision entsprechend entwickelt und markt- und kundenbezogene Veränderungen berücksichtigt werden. Dazu führt er eine Liste, in der Feedback von Benutzern und vom Entwicklerteam eingetragen wird. So lassen sich Prioritäten festlegen und die Übersicht bewahren, damit eine Bearbeitung der Punkte zu gegebener Zeit möglich ist. Mehr über die sinnvolle Pflege eines Backlogs erfährst du hier.

  2. Sprint-Planung: In diesem Meeting werden die durchzuführenden Aufgaben (der Umfang) für den aktuellen Sprint vom gesamten Entwicklerteam geplant. In diesem vom Scrum Master geleiteten Meeting legt das Team das Sprint-Ziel fest. Der Sprint wird dann durch konkrete User Storys aus dem Produkt-Backlog ergänzt. Diese Storys sind immer auf das Ziel ausgerichtet und werden vom Scrum-Team gemeinsam festgelegt, damit sie während des Sprints implementierbar sind.

    Am Ende des Planungsmeetings sollte jedem Scrum-Teammitglied klar sein, was im Sprint erledigt werden kann und wie das Inkrement ausgeliefert werden kann.

  3. Sprint: Ein Sprint ist der tatsächliche Zeitraum, in dem das Scrum-Team am Abschluss des Inkrements arbeitet. Typischerweise dauert ein Sprint zwei Wochen. Manche Teams finden einwöchige Sprints besser zu bewältigen, und wieder andere legen einen Monat fest, um ein wichtiges Inkrement auszuliefern. Dave West von Scrum.org empfiehlt, Sprints umso schneller abzuschließen, je komplexer die Aufgaben und je mehr Unbekannte vorhanden sind. Doch das liegt ganz bei eurem Team. Wenn etwas nicht funktioniert, solltet ihr euch nicht davor scheuen, Änderungen vorzunehmen. In dieser Zeit kann der Umfang der Aufgaben bei Bedarf gemeinsam von Produktinhaber und Entwicklerteam neu bestimmt werden. Das ist der Knackpunkt des erfahrungsbasierten Ansatzes von Scrum.

    Alle Ereignisse – von der Planung bis hin zur Retrospektive – finden während des Sprints statt. Wenn ein zeitlicher Rhythmus für einen Sprint festgelegt wurde, muss dieser über die gesamte Entwicklung hinweg beibehalten werden. So können Teams aus ihren Erfahrungen lernen und diese Erkenntnisse auf geplante Sprints anwenden.

  4. Daily Scrum oder Stand-up-Meeting: Darunter versteht man ein tägliches, sehr kurzes Meeting, das praktischerweise immer zur selben Zeit (meist morgens) und am selben Ort stattfindet. Viele Teams versuchen, das Meeting auf 15 Minuten zu beschränken. Das soll jedoch nur zur Orientierung dienen. Man spricht auch von einem "täglichen Stand-up-Meeting", was verdeutlicht, dass die Besprechung wirklich nur sehr kurz sein sollte. Mit dem Daily Scrum soll jeder im Team auf denselben Stand gebracht werden, sich auf das Sprint-Ziel ausrichten und einen Plan für die nächsten 24 Stunden entwickeln.

    Das Stand-up-Meeting bietet Gelegenheit, Bedenken zur Umsetzbarkeit des Sprint-Ziels und bezüglich Blockern zu äußern.

    Eine gängige Methode für Stand-up-Meetings sieht vor, dass jedes Teammitglied drei Fragen zum Erreichen des Sprint-Ziels beantwortet:

    •    Was habe ich gestern gemacht?
    •    Was will ich heute tun?
    •    Gibt es irgendwelche Hindernisse?

    Wir haben jedoch beobachtet, dass viele schnell dazu neigen, einfach ihre Kalendereinträge für den gestrigen und den kommenden Tag vorzulesen. Der Grundgedanke hinter Stand-up-Meetings ist jedoch, ablenkende Gespräche auf dieses Meeting zu beschränken, damit sich das Team für den Rest des Tages ganz auf seine Aufgaben konzentrieren kann. Wenn das Meeting also zum reinen Kalendervorlesen wird, scheut euch nicht, für Schwung zu sorgen und kreativ zu werden.

  5. Sprint-Review: Am Ende des Sprints kommt das Team in einer informellen Sitzung zusammen, um sich eine Demo des Inkrements anzusehen oder das Inkrement unter die Lupe zu nehmen. Das Entwicklerteam präsentiert die Backlog-Elemente, die jetzt abgeschlossen und für Feedback von Stakeholdern und Teamkollegen freigegeben sind. Der Produktinhaber entscheidet, ob das Inkrement veröffentlicht wird, was in den meisten Fällen auch geschieht.

    In diesem Review-Meeting überarbeitet der Produktinhaber zudem das Produkt-Backlog basierend auf dem aktuellen Sprint. Das Ergebnis kann dann in die nächste Sprint-Planungssitzung einfließen. Begrenzt den Sprint-Review für einen einmonatigen Sprint auf maximal vier Stunden.

  6. Sprint-Retrospektive: Bei einer Retrospektive dokumentiert und bespricht das Team, was in einem Sprint, einem Projekt, bei bestimmten Personen oder Beziehungen, bei Tools oder auch bestimmten Zeremonien funktioniert hat und was nicht. Der Schwerpunkt sollte dabei nicht so sehr auf den Misserfolgen liegen, sondern auf den Erfolgen und Verbesserungsmöglichkeiten.

Drei wesentliche Rollen für den Erfolg von Scrum

In einem Scrum-Team sind drei Rollen erforderlich: Produktinhaber, Scrum Master und Entwicklerteam. Da Scrum-Teams funktionsübergreifend sind, umfasst das Entwicklerteam neben den Entwicklern auch Tester, Designer, UX-Spezialisten und Betriebstechniker.  

Der Scrum-Product Owner

Produktinhaber sind verantwortlich für ihr Produkt. Sie konzentrieren sich darauf, Geschäfts-, Kunden- und Marktanforderungen zu analysieren und dann die für das Entwicklerteam anstehenden Arbeiten entsprechend zu priorisieren. Aufgaben effektiv arbeitender Produktinhaber:

  • Entwicklung und Management des Produkt-Backlogs
  • Enge Zusammenarbeit mit dem Unternehmen und dem Team, um sicherzustellen, dass alle die Aufgabenelemente im Produkt-Backlog verstehen
  • Klare Anweisungen an das Team, welche Features als Nächstes ausgeliefert werden sollen
  • Entscheidung, wann das Produkt ausgeliefert werden soll, mit Tendenz zu einer häufigeren Auslieferung

Der Produktinhaber ist nicht immer der Produktmanager. Produktinhaber konzentrieren sich darauf, sicherzustellen, dass das Entwicklerteam den für das Unternehmen größtmöglichen Wert schafft. Außerdem sollte der Produktinhaber unbedingt eine Einzelperson sein. Es wäre für ein Entwicklerteam alles andere als hilfreich, unterschiedliche Anweisungen von mehreren Produktinhabern zu erhalten.

Der Scrum Master

Scrum Master sind innerhalb ihres Teams für das Gelingen von Scrum verantwortlich. Sie coachen das Team, den Produktinhaber und das Unternehmen in Bezug auf den Scrum-Prozess und suchen nach Wegen, dessen Umsetzung abzustimmen.

Ein effektiv arbeitender Scrum Master hat ein tiefgehendes Verständnis für die vom Team ausgeführten Aufgaben und kann dem Team helfen, seine Transparenz und seinen Auslieferungsprozess zu optimieren. Als Hauptvermittler plant er die erforderlichen Ressourcen (sowohl Personal als auch Logistik) für die Sprint-Planung, die Stand-up-Meetings, den Sprint-Review und die Sprint-Retrospektive ein.

Das Scrum-Entwicklerteam

Scrum-Teams arbeiten produktiv. Sie sind Meister bei nachhaltigen Entwicklungsverfahren. Effektive Scrum-Teams arbeiten an einem gemeinsamen Standort eng zusammen und haben für gewöhnlich fünf bis sieben Mitglieder. Die Größe des Teams könnt ihr zum Beispiel mit der bekannten "Zwei-Pizza-Regel" von Jeff Bezos, dem CEO von Amazon, ausloten: Ein Team sollte sich zwei Pizzas teilen können.

Die Teammitglieder verfügen über unterschiedliche Kompetenzen und schulen sich gegenseitig, um durch Personen verursachte Engpässe bei der Umsetzung der Aufgaben zu verhindern. Erfolgreiche Scrum-Teams sind in der Lage, sich selbst zu organisieren, und gehen ihre Projekte mit einer klaren "Wir"-Haltung an. Alle Mitglieder des Teams unterstützen sich gegenseitig, um einen erfolgreichen Sprint-Abschluss sicherzustellen.

Das Scrum-Team steuert die Planung für jeden Sprint. Die Mitglieder prognostizieren anhand ihrer bisherigen Velocity, wie viel Arbeit sie ihrer Meinung nach im Verlauf der Iteration abschließen können. Eine feste Länge der Iteration gibt dem Entwicklerteam wichtiges Feedback zum Schätzungs- und Auslieferungsprozess, was wiederum die Prognosen mit der Zeit zunehmend präzisiert.

Scrum, Kanban und Agile

Das Agile-Framework Scrum ist so bekannt, dass Scrum und Agile oft fälschlicherweise für ein und dieselbe Lösung gehalten werden. Doch es gibt auch andere Frameworks, etwa die sehr beliebte Alternative Kanban. Manche Unternehmen wählen auch ein hybrides Modell aus Scrum und Kanban, das "Scrumban" oder "Kanplan" genannt wird und Kanban mit einem Backlog bezeichnet. 

Sowohl bei Scrum als auch bei Kanban lässt sich der Fortschritt der Arbeit z. B. mit dem Scrum Board oder dem Kanban Board visuell nachverfolgen. Beide Frameworks stellen die Effizienz heraus und teilen komplexe Aufgaben in kleinere, besser handhabbare Blöcke auf. Sie unterscheiden sich jedoch in ihrem Ansatz diesbezüglich.

Bei Scrum liegt der Schwerpunkt auf kleineren Iterationen mit einer festen Dauer. Sobald die Zeit für einen Sprint feststeht, werden die Storys oder Einträge des Produkt-Backlogs bestimmt, die während dieses Sprint-Zyklus implementiert werden können. Bei Kanban wird dagegen zuerst die Anzahl der Aufgaben oder laufenden Arbeiten (WIP-Grenze) festgelegt, die im aktuellen Zyklus zu implementieren sind. Die zum Implementieren dieser Features benötigte Zeit wird dann "rückwärts" berechnet.

Kanban ist weniger strukturiert als Scrum. Abgesehen von der WIP-Grenze kann das Framework frei ausgelegt werden. Scrum hingegen sieht mehrere kategorische Konzepte vor, die im Rahmen der Implementierung durchgesetzt werden, wie etwa Sprint-Reviews, Retrospektiven und Daily Scrums. Außerdem ist ein funktionsübergreifender Ansatz vorgegeben, was bedeutet, dass Scrum-Teams beim Erreichen ihrer Ziele nicht von externen Kollegen abhängig sind. Der Aufbau eines funktionsübergreifenden Teams ist jedoch nicht ganz einfach. In diesem Punkt lässt sich Kanban einfacher anpassen. Scrum hingegen bedeutet eine grundlegende Änderung des Denkansatzes und der Arbeitsweise von Entwicklerteams.

Was spricht für Scrum?

Das Scrum-Framework selbst ist einfach. Die Regeln, Artefakte, Ereignisse und Rollen sind leicht zu verstehen. Sein Ansatz ist nur teilweise festgesetzt und hilft sogar, Unklarheiten im Entwicklungsprozess zu beseitigen. Dabei haben Unternehmen zugleich genügend Raum, um eigene Akzente zu setzen.

Scrum ist durch die Aufteilung komplexer Aufgaben in gut handhabbare User Storys ideal für schwierige Projekte geeignet. Die klare Abgrenzung von Rollen und geplanten Ereignissen sorgt für Transparenz und fördert ein kollektives Verantwortungsgefühl im gesamten Entwicklungszyklus. Dank zügiger Releases bleibt das Team motiviert, und die Zufriedenheit der Kunden ist sichergestellt, da Benutzer bereits innerhalb kurzer Zeit Fortschritte erkennen können.

Das Entwicklerteam sollte allerdings Zeit zur Einarbeitung in Scrum einplanen, vor allem dann, wenn es zuvor mit einem typischen Wasserfallmodell gearbeitet hat. Kleinere Iterationen, tägliche Stand-up-Meetings, Sprint-Reviews und das Bestimmen eines Scrum Masters sind Konzepte, die neue Teams möglicherweise mit einem grundlegenden kulturellen Wandel konfrontieren.


Die langfristigen Vorteile sind jedoch den lernintensiven Einstieg wert. Die erfolgreiche Entwicklung komplexer Hardware- und Softwareprodukte in verschiedenen Branchen und Sektoren macht Scrum auch für dein Unternehmen zum attraktiven Framework.

 

Claire Drumond
Claire Drumond

Claire Drumond is a marketing strategist, speaker, and writer for Atlassian. She is the author of numerous articles published on the Trello and Atlassian blogs and is a regular contributor to various publications on Medium including HackerNoon, Art+Marketing, and PoetsUnlimited. She speaks at tech conferences around the world about agile, breaking down silos, and building empathy.

Weiter geht's
Sprints