Taking too long? Close loading screen.

Was ist Scrum?

EINLEITUNG

Scrum ist ein agiles Vorgehensmodell, das sich insbesondere für die Produktentwicklung eignet. Der Schwerpunkt liegt darin, Entwicklungs-Teams so zu befähigen, dass sie in der Lage sind, dynamisch und flexibel auf neue Situationen zu reagieren. Beispiele hierfür sind: Neue Kundenanforderungen im laufenden Projekt, die Berücksichtigung technischer Innovationen/Weiterentwicklungen, aber auch eine möglicherweise veränderte Marktsituation (zum Beispiel ein Wettbewerber, der mit einem ähnlichen Produkt den Markt adressiert).

Durch kleine Teams, die in Absprache mit Stakeholdern Produktziele formulieren, jedoch in deren Umsetzung selbstbestimmt bleiben, werden fortlaufend kleine Product Increments released. Das ermöglicht zeitnahes Feedback und ein empirisches, inkrementelles und iteratives Vorgehen.

,,Scrum ist leichtgewichtig, einfach zu verstehen, schwierig zu meistern.‘‘ (Schwaber & Sutherland, 2016, S.3)

Ausgangspunkt für Scrum bietet der Scrum Guide von Ken Schwaber und Jeff Sutherland.
In diesem wird die agile Methode explizit als ein Rahmenwerk und nicht als starre Vorlage definiert, welches stetig an die individuellen Bedürfnisse und (Produkt) Kontexte durch das Scrum Team angepasst werden kann.

Scrum beschreibt in seiner Theorie 1 Scrum Team, 5 Events und 3 Artefakte.

Das von uns designte Plakat basiert primär auf der neuesten Version (2020) des Scrum Guides und bietet dir einen fundierten Überblick zum Framework. Zusätzlich haben wir verschiedene „Good Practices“ formuliert, die aus unserer direkten Kundenerfahrung resultieren und wertvolle Tipps geben.

Die Vorteile von Scrum

NUTZE Was am besten ist

Scrum integriert Produktionsprozess und empirischen Lernprozess, wobei mehrere Ebenen von Feedback-Zyklen innerhalb des Projektteams und mit der Projektumgebung verbunden werden. Die Identifikation und Priorisierung von Verbesserungsmöglichkeiten sind Prozessbestandteil. Etwaige Innovationspotenziale können so sicher erkannt und direkt umgesetzt werden.

FLEXIBILITÄT

INNOVATIONSFÄHIG­KEIT

LEISTUNGSQUA­LITÄT

PROAKTIVE KOMMUNIKATION

PLANUNG

MOTIVATION UND ERFOLG

DAS SCRUM PLAKAT

Der Scrum-Überblick für deine Wand – oder deinen Bildschirm.
Alles Wichtige an einem Ort.

Mit dem Scrum Plakat bieten wir dir eine übersichtliche Visualisierung des gesamten Prozesses mit detaillierten Beschreibungen aller wichtigen Elemente.

Unser Add-on: Good Practices für den operativen Einsatz von Scrum.
Direkte Kundenerfahrung von uns für dich.

TEAM, Events, Artefakte & Werte

Wie FUNKTIONIERT SCRUM?

Scrum Team

Developer

Umsetzungsexperten

Developer sind Fachexperten, deren spezifische Fähigkeiten je nach Kontext weit gestreut sind.

Sie sind ergebnisverantwortlich für

Product Owner

Value Maximizer

Der Product Owner entwickelt auf Basis der Produkt Vision ein Product Goal und ist verantwortlich, dieses zu erreichen bzw. ihm möglichst nahezukommen.
Je Produkt gibt es nur einen Product Owner, der als letzte Instanz über Änderungswünsche bestimmen kann.

Er ist ergebnisverantwortlich für

Scrum Master

True Leader

Kernaufgabe eines Scrum Masters ist es, dem Scrum Team und den Menschen innerhalb der Organisation eine selbstbestimmte Arbeitsweise näherzubringen. Dies gelingt ihm, indem er eine agile Arbeitsweise und die Scrum Theorie (Regeln, Praktiken und Werte) vorlebt und lehrt. Jedes Team hat einen Scrum Master. Scrum Master sind ergebnisverantwortlich für die Effektivität des Scrum Teams.

Scrum Master kümmern sich

… um das Scrum Team, indem sie

… um den Product Owner, indem sie

… um die Organisation, indem sie

Events

Bis zu 120 Min pro Sprint Woche

Sprint planning

Findet am Anfang
eines jeden Sprints Statt

Warum machen wir einen nächsten Sprint? 
Das Scrum Team erarbeitet ein gemeinsames Sprint Goal auf Basis des Product Goal. Dadurch wird erklärt, welchen Mehrwert der Sprint für das Produkt und die Stakeholder transportiert.

Was können wir im nächsten Sprint umsetzen?
Das Sprint Backlog wird mit Elementen des Product Backlogs bestückt, welche das Erreichen des Sprint Goals optimal unterstützen.

Wie möchten wir unsere Arbeit organisieren, um unser Sprint Goal zu erreichen?
Die Developer definieren auf Basis von Qualitätsstandards (DoD) einzelne Aufgaben zur Umsetzung des Sprint Goals. Diese werden im Sprint Backlog hinterlegt.

Bis zu 4 Wochen

Sprint

MAximal 4 Wochen

Wie können wir als Scrum Team zielgerichtet Produktincremente entwickeln?

Bis zu 15 Min pro Event

Daily Scrum

Tägliches Event
mit festen Rahmenbedingungen

Wie sieht unser Fortschritt im Hinblick auf das zu erreichende Sprint Goal aus? 

Wie und an was werden wir bis zum nächsten Daily Scrum arbeiten?
Durch das Daily Scrum werden folgende Dinge erreicht:

Das Daily Scrum findet jeden Arbeitstag am gleichen Ort zur gleichen Zeit statt. Die Art der Durchführung bleibt den Developern überlassen.

Bis zu 60 Min pro Sprint Woche

Sprint Review

Vorletztes Event
des Sprints

Welche Fortschritte gab es im letzten Sprint zur Erreichung des Product Goals? Welche Erkenntnisse ziehen wir daraus?

Bis zu 45 Min pro Sprint Woche

Sprint Retrospective

Schließt den sprint ab

Wie können wir unsere Qualität und Effektivität verbessern?
Durch die Analyse des vergangenen Sprints in Bezug auf

erarbeiten wir die hilfreichsten Änderungen und können diese so schnell wie möglich in Angriff nehmen, indem wir sie z.B. im nächsten Sprint mit umsetzen.

ARTEFAKTE

Product Backlog

,,Das, was wir umsetzen‘‘
Commitment: Product Goal

,,Was soll mit dem Produkt erreicht werden?‘‘

Sprint Backlog

,,Wie wir es umsetzen‘‘
Commitment: Sprint Goal

,,Warum machen wir einen Sprint?‘‘

Increment

,,Konkreter Schritt in Richtung des Product Goals‘‘
Commitment: Definition of Done

,,Was sind unsere Qualitätsansprüche‘‘

WERTE

Commitment

Das Scrum Team

C

Mut

Das Scrum Team

M

FoKus

Das Scrum Team

F

Offenheit

Das Scrum Team

O

Respekt

Das Scrum Team

R

GOOD PRACTICES

WIE LÄSST SICH SCRUM OPTIMIEREN?

„Fail fast.“ – Autor unbekannt

Wir empfehlen automatisierte Tests, da sie es ermöglichen, Fehler im Code und der Funktionalität schnell zu erkennen und auszubessern. Getestet werden nicht nur Neuentwicklungen, sondern auch Auswirkungen auf das gesamte Produkt. Dabei ist der Kosten-/Nutzen-Faktor zu betrachten: Da eine Testautomatisierung aufwändig sein kann, konzentriert man sich auf die wichtigen Funktionen, die entscheidend für die Nutzung des Produktes sind (risikobasiert).
Automatisierte Tests ersetzen manuelle Tests nicht vollständig. Wir empfehlen, automatisierte Tests möglichst früh in der Entwicklung zu berücksichtigen und Akzeptanzkriterien als Grundlage zu nutzen

„You build it you run it.” – Werner Vogels

Wir leben DevOps, da sich das Team ganzheitlich um die Anwendung kümmert und komplexe Software-Übergabeprozesse nicht mehr notwendig sind. So liegt die Verantwortung bei den Experten, die sie entwickelt haben.
Von der Entwicklung, über die Integration der Komponenten, zum Go-Live und weiter zur Überwachung der laufenden Anwendung – alles liegt in der Verantwortung des Teams.

„The most powerful tool we have as developers is automation.” – Scott Hanselman

Wir nutzen Continuous Integration, um sicherzustellen, dass unser Code nach jedem Commit noch lauffähig ist und unsere Qualitätskriterien (z.B. Testabdeckung) weiterhin erfüllt sind. Eine automatisierte Pipeline hilft uns dabei.
Continuous Delivery ist der automatisierte Schritt des Deployments der Anwendung in die Produktion, sobald alle notwendigen Qualitätskriterien erfüllt sind.

,,Ein Backlog ist nie komplett und nie vollständig‘‘ – Tim Buchner

Wir empfehlen regelmäßige Refinement Events, wenn das Team es noch nicht gewohnt ist, sich ausreichend mit der Weiterentwicklung des Backlogs zu beschäftigen. Es stellt ein gemeinsames Zeitfenster dar, in dem sich das Scrum Team mit dem Backlog auseinandersetzen kann. Dieses kann um Details wie Beschreibung, Reihenfolge und Größe ergänzt werden. Die Attribute variieren oft je nach Arbeitsumfeld.
Ein solches Event ist auch dann sinnvoll, wenn man Stakeholder außerhalb des Teams in das Refinement mit einbeziehen möchte.

,,Denken heißt vergleichen‘‘ – Walther Rathenau

Wir nutzen Referenz Product Backlog Einträge, um für die Schätzung des Aufwands neuer Einträge eine gesunde Basis zu schaffen. Dadurch fällt es Teams deutlich leichter, neue Anforderungen in Relation zu diesen einzuschätzen.
Wichtig ist es immer wieder zu überprüfen, ob bisherige Referenz Product Backlog Einträge noch als solche sinnvoll sind; andere technologische Schwerpunkte oder ein tieferes Verständnis des Produktes und der verwendeten Technologien können Komplexitäten verändern.

„Keep it simple and get rid of the big cards.” – Autor unbekannt

Wir benutzen Planning Poker für die Schätzung unserer Product Backlog Einträge, um Meinungen und Expertisen einzelner Teammitglieder besser zur Geltung zu bringen.
Während eines Refinement Events werden Diskussionen durch sehr unterschiedliche Schätzungen angestoßen und voneinander unabhängige Gedankengänge im Team zugelassen.

,,Wer zu schnell geht, kommt oft nicht mit‘‘ – Anke Maggauer-Kirsche

Wir empfehlen, dass Teams ihre Velocity messen, um in zukünftigen Sprints besser abschätzen zu können, wieviel Komplexität sie in einem Sprint schaffen können.
Velocity beschreibt die Menge der erledigten Arbeit, die ein Team in einem Sprint geschafft hat (kann z.B. mit Story Points gemessen werden). Hier werden nur die Product Backlog Einträge herangezogen, die gemäß der „Definition of Done“ geschlossen wurden.
Auf keinen Fall darf Velocity zur Bewertung oder zum Vergleich von Teams herangezogen werden.
Schwankungen sind hierbei völlig normal. Nach einer bestimmten Zeit sollte sich ein gewisses Gefühl im Team entwickeln.

„Hör nicht auf, wenn es wehtut. Hör auf, wenn du fertig bist.” – Autor unbekannt

Wir nutzen eine „Definition of Ready”, um sicherzustellen, dass auch in den Product Backlog Einträgen alle Aspekte beachtet wurden, die zur Umsetzung notwendig sind. Vergleichbar mit einer „Definition of Done” werden Kriterien festgelegt, die erfüllt sein müssen, bevor das Product Backlog Eintrag in den Sprint Backlog übernommen wird. Ein paar Beispiele, die enthalten sein können:

  • Geschätzt
  • Klein genug, um in einem Sprint erledigt zu werden
  • Möglichst keine Abhängigkeiten zu anderen Backlog-Einträgen (technisch wie fachlich)
  • Von allen Teammitgliedern verstanden
  • Sicherheitsrelevante Aspekte beachtet

„You’ll never walk alone.” – Richard Rodgers

Wir empfehlen beim Daily Scrum die Methode „Walk the Board“, wenn mehr als eine Story gleichzeitig aktiv bearbeitet wird. Jeder Sprint Backlog Eintrag wird durchgegangen und der aktuelle Stand sowie eventuell aufgetretene Impediments besprochen.
Es ist sinnvoll, sich auf eine festgelegte Reihenfolge zu einigen. Zum Beispiel nach Priorisierung im Sprint Backlog oder am weitesten fortgeschritten in der Umsetzung (von rechts nach links). Dadurch wird ein häufiger Kontextwechsel vermieden.

,,Erfolg ist eine Treppe, keine Tür‘‘ – Dottie Walters

Wir empfehlen, den Fortschritt des Teams während eines Sprints mit einem Burndown Chart zu visualisieren. Dabei wird jeden Tag die geleistete Arbeit in Relation mit dem Zeitverlauf des Sprints gesetzt, beginnend mit der voraussichtlichen Gesamtarbeitsmenge. Dies bietet einen schnellen Überblick auf die noch zu leistende Arbeit und hilft zu erkennen, ob Impediments das Team blockieren und wie gut die Arbeitspakete aufgeteilt sind.
Der Graph wird jeden Tag aktualisiert und ähnelt im Idealfall einer Rutsche oder einer Treppe (bei Jira).

Das Ganze ist mehr als die Summe seiner Teile.“  – Aristoteles.

Für uns ist Mob Programming zu einem wichtigen Bestandteil des Entwickleralltags geworden. Wir finden es klasse, wenn mehrere Entwickler gemeinsam an einem Problem arbeiten können.
Nicht nur die Qualität des Codes wird (bereits während seiner Erstellung) gesichert, auch Wissensinseln innerhalb des Teams werden vermieden.

„Es hört doch jeder nur, was er versteht.“ – J.W. Goethe

Wir nutzen Behaviour Driven Development in Verbindung mit einer „ubiquitous language“, also einer allgegenwärtigen, für alle verständlichen und auf der Fachdomäne basierenden Sprache, um Verständnisprobleme zwischen Fachexperten, Developern und anderen Stakeholdern zu minimieren und ein gemeinsames Verständnis von der Anwendung zu entwickeln.
Da die Tests während oder besser noch vor der Entwicklung des Codes erstellt werden und das Verhalten der Anwendung in einer semi-formalen Syntax (z.B. gherkin) beschreiben, ist allen Beteiligten von Anfang an klar, wie die Anwendung nach der Implementierung eines neuen Features funktionieren soll.

DAS SCRUM-PLAKAT

ZUM DOWNLOAD
Din A1

Das vollständige Plakat mit allen drei Schalen. Von dieser Version gibt es natürlich auch wieder gedruckte Exemplare im Format DIN A1.

Din A2

Schale 1+2 zusammen. Diese Version enthält bereits eine vollständige Beschreibung von Scrum. Wir haben sie auf eine Größe von DIN A2 (entspricht 4 DIN A4-Seiten) entworfen. Allerdings kann man auch bei einem Ausdruck auf A3 alles noch recht gut erkennen. 

Din A4

Nur Schale 1 mit dem Scrum-Prozess alleine. Sie passt bequem auf eine DIN A4-Seite bzw. eine einzelne (Powerpoint-) Folie. Sie eignet sich z.B. für Vorträge zum Thema Scrum.

DAS SCRUM-PLAKAT

Kostenlos ALS POSTER
Din A1
kostenlos bestellen

Das vollständige Plakat mit allen drei Schalen. Von dieser Version gibt es natürlich auch wieder gedruckte Exemplare im Format DIN A1. Diese Plakate kannst du gedruckt auf DIN A1 ganz einfach und formlos kostenlos bei uns bestellen.

Nachdem unser > SCRUM-Plakat so großen Anklang gefunden hat, haben wir uns entschieden auch ein Plakat zu KANBAN in IT-Prozessen zu machen. Das Plakat steht als Download zur Verfügung oder kann bei uns als Poster kostenlos > bestellt werden.

Das KANBAN-Plakat zum Download >>> DIN A1

Über Anregungen freuen wir uns jederzeit!

Scrum-Plakat
als Poster bestellen

Füll einfach das nebenstehende Formular mit deinen Kontaktdaten aus und wir senden dir kostenfrei das Plakat zu.

Download
SCrum-Plakat

Füll einfach das nebenstehende Formular mit deinen Kontaktdaten aus und wir senden dir innerhalb der nächsten Minuten das Plakat als PDF an deine E-Mail Adresse.