Close

Scrum

Nutzt die Stärken von Scrum mit unseren Profi-Tipps

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, durch 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 treffen auf alle Arten von Teamwork zu. Darin liegt einer der Gründe, weshalb Scrum so beliebt ist. 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 euch mithilfe des Scrum-Leitfadens 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:

Agile-Pfeil

Mit der Jira Scrum-Vorlage kostenlos loslegen

Vorlage verwenden

Artikel zu Scrum

[FORTSETZUNG]

Das Scrum-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". Die Hingabe des gesamten Teams ist nötig, um einen neuen Denkansatz zur Wertschöpfung für den Kunden zu finden. Doch ein Framework wie Scrum kann euch helfen, diese neue Denkweise zu verfolgen und die tägliche Kommunikation sowie die täglichen 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.

Ein Diagramm des Scrum-Frameworks

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.

Das Scrum-Team

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

Product Owner 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 Product Owner:

  • Entwickeln und Managen 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 Product Owner ist nicht immer der Produktmanager. Product Owner konzentrieren sich darauf, sicherzustellen, dass das Entwicklerteam den für das Unternehmen größtmöglichen Wert schafft. Außerdem sollte der Product Owner unbedingt eine Einzelperson sein. Kein Entwicklerteam braucht unterschiedliche Anweisungen von mehreren Product Ownern.

Der Scrum Master

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

Ein effektiv arbeitender Scrum Master hat ein tief gehendes 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 sind echt produktiv. Sie sind verantwortlich für nachhaltige Entwicklungsverfahren. Effektive Scrum-Teams arbeiten eng an einem gemeinsamen Standort 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 Auslieferung 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 Scrum-Abschluss sicherzustellen.

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

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 Hauptliste mit den zu erledigenden Aufgaben. Sie wird vom Produktinhaber oder Produktmanager verwaltet. Diese dynamische Liste von Features, Anforderungen, Verbesserungen und Fehlerbehebungen fließt in den 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 womöglich 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), an welchen Elementen aus dem Produkt-Backlog es in einem Sprint arbeiten will. 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.
  • 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 einen Release bereitzustellen. Ihr angestrebtes Ziel lautet also "ausliefern". Für andere Teams ist dieses Ziel womöglich 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 aufeinander folgenden 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 Product Owner verantwortlich. Der Product Owner ist vor allem dafür zuständig, dass das Produkt sich der Produktvision entsprechend entwickelt, und markt- und kundenbezogene Veränderungen zu verfolgen. Dazu führt er eine Liste, in der Feedback von Benutzern und dem Entwicklerteam eingetragen werden. So können Prioritäten festgelegt und die Übersicht bewahrt werden, damit eine Bearbeitung der Punkte zu gegebener Zeit möglich ist. Mehr über die sinnvolle Pflege eines Backlogs erfahrt ihr hier.

  2. Sprint planning: The work to be performed (scope) during the current sprint is planned during this meeting by the entire development team. This meeting is led by the scrum master and is where the team decides on the sprint goal. Specific user stories are then added to the sprint from the product backlog. These stories always align with the goal and are also agreed upon by the scrum team to be feasible to implement during the sprint.

    At the end of the planning meeting, every scrum member needs to be clear on what can be delivered in the sprint and how the increment can be delivered.

  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 wenn nötig gemeinsam von Product Owner 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. Tägliche Scrums oder Stand-up-Meetings: Darunter versteht man ein tägliches, sehr kurzes Meeting, das praktischerweise immer zur selben Zeit (meist morgens) und am selben Ort stattfindet. Viele Teams wollen das Meeting auf 15 Minuten 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. Im täglichen 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 zu äußern, die beim Erreichen des Sprint-Ziels und bezüglich Hindernissen bestehen.

    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, dass sich ablenkende Gespräche auf ein tägliches Meeting beschränken, damit das Team sich auf die Aufgaben des restlichen Tages 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 den Inkrement unter die Lupe zu nehmen. Das Entwicklerteam präsentiert die Backlog-Elemente, die jetzt erledigt und für Feedback von Stakeholdern und Teamkollegen freigegeben sind. Der Product Owner entscheidet, ob der Inkrement releast wird, was in den meisten Fällen aber auch geschieht.

    In diesem Review-Meeting überarbeitet der Product Owner zudem den 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 diskutiert das Team darüber, was in einem Sprint, einem Projekt, bei bestimmten Personen oder Beziehungen, bei Tools oder auch bestimmten Zeremonien funktioniert hat und was nicht. Das soll dem Team die Möglichkeit geben, sich nicht auf Misserfolge, sondern auf Erfolge zu konzentrieren und herauszustellen, was beim nächsten Mal besser laufen muss.

Agile-Pfeil

Mit der Jira Scrum-Vorlage kostenlos loslegen

Vorlage verwenden

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, wie 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 in Scrum als auch in 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, übersichtlichere Blöcke auf. Dabei unterscheiden sie sich jedoch in ihrem Ansatz.

Scrum legt einen Schwerpunkt auf kleinere Iterationen mit einer festen Dauer. Sobald die Zeit für einen Sprint abgelaufen ist, werden die Storys oder Einträge des Produkt-Backlogs bestimmt, die während dieses Sprint-Zyklus implementiert werden können. In Kanban werden jedoch die Anzahl der Aufgaben oder die laufenden Arbeiten (WIP-Grenze), die im aktuellen Zyklus zu implementieren sind, zuerst festgelegt. Die Zeit, die zur Implementierung dieser Features benötigt wurde, wird dann im Nachhinein 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 erzwungen werden, wie etwa Sprint-Reviews, Retrospektiven, tägliche Scrums etc. Außerdem ist ein funktionsübergreifendes Vorgehen 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. Jedoch ermöglicht Scrum eine grundlegende Änderung des Denkansatzes und der Arbeitsweise von Entwicklerteams.

Commitment

Because scrum teams are small and agile, each team member plays a significant role in the team’s success. Therefore, each team member should agree to commit to performing tasks they can complete and not overcommit. There should be frequent communication regarding work progress, often in stand-ups.

Courage

Courage for a scrum team is simply the bravery to question the status quo or anything that hampers its ability to succeed. Scrum team members should have the courage, and feel safe enough, to try new things. A scrum team should have the courage and feel safe to be transparent about roadblocks, project progress, delays, and so on.

Focus

At the heart of the workflow for scrum teams is the sprint, a focused and specified period of time where the team completes a set amount of work. The sprint provides structure but also focus to complete the planned amount of work.

Openness

The daily stand-up fosters an openness that allows teams to talk openly about work in progress and blockers. At Atlassian we often have our scrum teams address these questions:

  • What did I work on yesterday?
  • What am I working on today?
  • What issues are blocking me?

This helps to highlight progress and identify blockers. It also helps to strengthen the team when everyone shares progress.

Respect

The strength of an agile team lies in its collaboration and recognizing that each team member contributes to work in a sprint. They celebrate each other’s accomplishments and are respectful to one another, the product owner, stakeholders, and the scrum master.

Scrum, kanban, and agile

Scrum is such a popular agile framework that scrum and agile are often misunderstood to be the same thing. But there are other frameworks, like kanban, which is a popular alternative. Some companies even choose to follow a hybrid model of scrum and kanban, which has acquired the name of "Scrumban" or "Kanplan," which is Kanban with a backlog.  

Both scrum and kanban use visual methods such as the scrum board or kanban board to track the progress of work. Both emphasize efficiency and splitting complex tasks into smaller chunks of manageable work, but their approaches towards that goal are different.

Scrum focuses on smaller, fixed-length iterations. Once the time period for a sprint is finalized, the stories or product backlog entries that can be implemented during this sprint cycle are then determined. In kanban, however, the number of tasks or the work in progress (WIP limit) to be implemented in the current cycle is fixed at first. The time taken to implement these features is then calculated backward.

Kanban is not as structured as scrum. Other than the WIP limit, it is fairly open to interpretation. Scrum, however, has several categorical concepts enforced as part of its implementation such as sprint review, retrospective, daily scrum, etc. It also insists on cross-functionality, which is the ability of a scrum team to not depend on external members to achieve their goals. Putting together a cross-functional team is not straightforward. In that sense, kanban is easier to adapt whereas scrum can be considered as a fundamental shift in the thought process and functioning of a development team.

Was spricht für Scrum?

Das Scrum-Framework selbst ist einfach. Regeln, Artefakte, Ereignisse und Rollen sind leicht verständlich. Sein Ansatz ist nur teilweise festgesetzt und hilft sogar, Unklarheiten im Entwicklungsprozess zu beseitigen. Dabei haben Unternehmen zugleich genügend Raum, um ihren eigenen Akzent 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.

Jedoch muss das Entwicklerteam Zeit zur Einarbeitung einplanen, vor allem dann, wenn die Entwickler es gewohnt waren, mit einem typischen Wasserfallmodell zu arbeiten. Kleinere Iterationen, tägliche Scrum-Meetings, Sprint-Reviews und das Bestimmen eines Scrum Masters sind Konzepte, die neue Teams womöglich mit einem grundlegenden kulturellen Wandel konfrontieren.

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

Mehr zu Scrum-Projekten in Jira Software erfährst du in diesem Tutorial.

Claire Drumond
Claire Drumond

Claire Drumond ist Marketingstrategin, Sprecherin und Texterin für Atlassian. Sie hat zahlreiche Artikel verfasst, die auf Trello- und Atlassian-Blogs erschienen sind, und wirkt regelmäßig an Veröffentlichungen auf Medium mit, darunter HackerNoon, Art+Marketing sowie PoetsUnlimited. Auf Technologiekonferenzen weltweit spricht sie über agile Methoden, das Aufbrechen von Silos und den Aufbau von Empathie.

Weiter geht's
Sprints