Scrum ist

… ein Rahmenwerk

… leichtgewichtig

… einfach zu verstehen

… schwierig zu meistern

… kein Prozess, keine Technik und keine vollständige Methode

… 

Das Scrum Rahmenwerk

… wird zur Entwicklung, Auslieferung und Erhaltung komplexer Produkte eingesetzt

… wird als Prozessrahmenwerk zum Management der Arbeit an komplexen Produkten verwendet

… versetzt Menschen in die Lage komplexe adaptive Aufgabenstellungen anzugehen und dadurch produktiv und kreativ Produkte mit höchstmöglichen wert auszuliefern

… ist ein Rahmenwerk, innerhalb dessen verschiedene Prozesse und Techniken zum Einsatz gebracht werden können

Scrum macht die relative Wirksamkeit Ihres Produktmanagements und Ihrer Arbeitstechniken sichtbar, damit Sie fortlaufend das Produkt, das Team und die Arbeitsumgebung verbessern können.

 

Das Scrum Rahmenwerk besteht aus:

  • Jede Komponente innerhalb des Rahmenwerks dient einem bestimmten Zweck und ist unentbehrlich für den Einsatz von Scrum und dessen Erfolg.
  • Das Scrum Team kennt drei Rollen: Product Owner, Scrum Master und Entwicklungs-Team.
  • Das Scrum Team führt während eine Sprints die vier Time-Boxed Event-Aktivitäten „Sprint Planning“, “ Daily Scrum“, “ Sprint Review“ und „Sprint Retrospektive“ aus.
  • Dabei werden die drei Haupt-Inkremente „Product Backlog“, „Sprint Backlog“ und „Das PSPI ( Potentially Shipable Product Increment)“ erstellt und bearbeitet.

 

Scrum

… basiert auf die Theorie „empirischer Prozesssteuerung“ oder kurz „Empirie“

… verfolgt einen iterativen und inkrementellen Ansatz

… basiert auf drei tragende Säulen der empirischen Prozesssteuerung

  • Tranzparenz
  • Überprüfung
  • Anpassung

Empirie bedeutet, dass Wissen aus Erfahrung gewonnen wird und Entscheidungen auf Basis des Bekannten getroffen werden.

 

Die Scrum Werte sind:

  • Selbstverpflichtung
  • Mut
  • Fokus
  • Respekt
  • Offenheit

Wenn die Werte durch das Scrum-Team verkörpert und gelebt werden, werden die Scrum-Säulen Transparenz, Überprüfung und Anpassung lebendig und bauen bei allen Beteiligten Vertrauen auf.

Die Mitglieder des Scrum-Teams lernen und erforschen diese Werte, indem sie mit den Scrum-Ereignissen, Rollen und Artefakten arbeiten. Der erfolgreiche Einsatz von Scrum beruht darauf, dass alle Beteiligten kompetenter bei der Erfüllung dieser fünf Werte werden.

 

Scrum wird genutzt zur:

  • Erforschung und Identifizierung rentabler Märkte, Technologien und Produktfähigkeiten
  • Entwicklung von Produkten und Verbesserungen
  • Erhaltung und Erneuerung von Produkten
  • Auslieferung von Produkten und Verbesserungen, auch vielfach pro Tag
  • Entwicklung und Aufrechterhaltung von Cloud-Umgebungen (online, secure, on-demand) und anderer Produktivumgebungen

 

Die Rollen im Scrum Team

Ein Scrum-Team besteht aus dem Product Owner, dem Entwicklungsteam, sowie dem Scrum Master.

Scrum-Teams sind selbstorganisierend & interdisziplinär (Funktionsübergreifend), kollektiv Verantwortlich und beweisen Teamgeist

  • Selbstorganisierende Teams entscheiden selbst, wie sie ihre Arbeit am besten erledigen, anstatt dieses durch andere Personen außerhalb des Teams vorgegeben zu bekommen.
  • Interdisziplinäre Teams verfügen über alle Kompetenzen, die erforderlich sind, um die Arbeit zu erledigen, ohne dabei von Personen außerhalb des Entwicklungsteams abhängig zu sein.
  • Das Team-Modell in Scrum wurde konzipiert, um Flexibilität, Kreativität und Produktivität zu optimieren.
  • Es hat sich herausgestellt, dass ein Scrum-Team für alle eingangs aufgeführten Anwendungsfälle und jegliche komplexe Arbeit in zunehmende Maße effektiver wird.
  • Scrum-Teams liefern Produkte iterativ und inkrementell und maximieren somit die Gelegenheiten für Feedback.
  • Die inkrementelle Auslieferung eines „fertigen“ [Done] Produkts sorgt dafür, dass stets eine potentiell nützliche Version des Produkts zur Verfügung steht.

 

Scrum Events (Ereignisse)

In Scrum werden die vorgeschriebene Ereignisse Sprint Planning, Daily Scrum, Sprint Review, Sprint Retrospektive sowie Backlog Grooming verwendet, um eine Regelmäßigkeit herzustellen und die Notwendigkeit anderer, nicht in Scrum definierter, Besprechungen zu minimieren.

  • Alle Ereignisse finden in einem Sprint statt.
    • Alle Ereignisse sind befristet [time boxed], so dass jedes Ereignis eine maximale Dauer hat
    • Die Dauer eines Sprints steht zu seinem Beginn fest und darf weder gekürzt noch verlängert werden
    • Die anderen Ereignisse dürfen beendet werden, sobald sie ihren Zweck erfüllt haben. Dies stellt sicher, dass nur so viel Zeit wie nötig aufgewendet und Verschwendung vermieden wird
    • Diese Ereignisse sind dazu gedacht, an den kritischen Stellen Transparenz, Überprüfung und Anpassung zu ermöglichen
  • Mit Ausnahme des Sprints als Container für alle anderen Ereignisse ist jedes Scrum-Ereignis eine formale Gelegenheit zur Überprüfung und Anpassung
  • Das Weglassen irgendeines dieser Ereignisse führt zu verringerter Transparenz und ist eine verpasste Gelegenheit den gegenwärtigen Stand zu erfassen [Inspect] und darauf zu reagieren [Adapt]

Sprint Planning

Im Sprint Planning wird die Arbeit für den kommenden Sprint geplant

  • Dieser Plan entsteht durch die gemeinschaftliche Arbeit des gesamten Scrum-Teams

Das Sprint Planning ist für einen einmonatigen Sprint auf maximal 8 Stunden befristet [Time Box]

  • Bei kürzeren Sprints wendet man normalerweise weniger Zeit auf

Der Scrum Master sorgt dafür, dass das Ereignis stattfindet und die Teilnehmer dessen Zweck verstehen

  • Er bringt dem Scrum-Team bei, das Ereignis innerhalb der Frist erfolgreich abzuschließen

Das Sprint Planning beantwortet die folgenden Fragen:

  • Was ist in dem Produktinkrement des kommenden Sprints enthalten?
  • Wie wird die für die Lieferung des Produktinkrements erforderliche Arbeit erledigt?
  • Was sind die Sprint Ziele?
  • Welche und wie viele Product Backlog Items werden in den Sprint Backlog für den Sprint aufgenommen?

Daily Scrum

Das Daily Scrum ist ein entscheidendes Meeting zur Überprüfung und Anpassung

Das Daily Scrum ist eine Time Box von 15 Minuten für das Entwicklungsteam

    • Das Daily Scrum findet an jedem Tag des Sprints statt.
    • Um die Komplexität zu reduzieren, wird das Daily Scrum an jedem Tag zur gleichen Uhrzeit am gleichen Ort abgehalten
    • Das Entwicklungsteam plant dabei die Arbeit für die nächsten 24 Stunden.
    • Es überprüft die Arbeitsergebnisse seit dem letzten Daily Scrum und prognostiziert die im Sprint bevorstehende Arbeit, um die Zusammenarbeit und Leistung des Teams zu optimieren.

Das Entwicklungsteam überprüft im Daily Scrum seinen Fortschritt in Richtung des Sprint-Ziels und den Trend bei der Abarbeitung der Sprint Backlog-Einträge

Sprint Review

Am Ende eines Sprints wird ein Sprint Review abgehalten, um das Produktinkrement zu überprüfen und das Product Backlog bei Bedarf anzupassen

    • Während des Sprint Reviews beschäftigen sich das Scrum-Team und die Stakeholder gemeinsam mit den Ergebnissen des Sprints
    • Zusammen mit eventuellen „Änderungen am Product Backlog während des Sprints“ (Product Backlog Refinement) bieten diese die Basis für die gemeinsame Arbeit an möglichen neuen, den Wert des Produkts steigernden Punkten
    • Beim Sprint Review handelt es sich um ein informelles Meeting und keinen Statusreport
    • Die Vorführung des Inkrements ist als Anregung für Feedback und die Basis für die Zusammenarbeit gedacht

Für einen einmonatigen Sprint wird für dieses Meeting eine Obergrenze [Time Box] von vier Stunden angesetzt

    • Für kürzere Sprints wird in der Regel ein kürzerer Zeitrahmen veranschlagt

Der Scrum Master kümmert sich um die Organisation des Meetings und die Vorbereitung der Teilnehmer

  • Er zeigt allen Beteiligten, wie sie das Meeting innerhalb der Frist halten können

Das Ergebnis des Sprint Reviews ist ein überarbeitetes Product Backlog, das die möglichen Product-Backlog-Einträge für den kommenden Sprint enthält

    • Das Product Backlog kann auch umfassend umgearbeitet werden, um neue Chancen zu nutzen

Sprint Retrospektive

In Scrum bietet Sprint Retrospektive dem Scrum-Team die Gelegenheit, sich selbst zu überprüfen und einen Verbesserungsplan für den kommenden Sprint zu erstellen

Sie findet zwischen dem Sprint Review und dem nächsten Sprint Planning statt.

  • Für einen einmonatigen Sprint wird hierfür eine Obergrenze von drei Stunden angesetzt. Bei kürzeren Sprints ist das Meeting in der Regel kürzer
  • Der Scrum Master sorgt dafür, dass das Meeting stattfindet und alle Teilnehmer dessen Zweck verstehen
  • Der Scrum Master sorgt dafür, dass das Meeting konstruktiv und produktiv ist
  • Der Scrum Master lehrt alle, die Time Box einzuhalten
  • Aufgrund seiner Verantwortung für den Scrum-Prozess nimmt der Scrum Master als gleichberechtigtes Mitglied an der Sprint Retrospektive teil
  • Der Scrum Master bestärkt das Scrum-Team darin, seine Entwicklungsprozesse und -praktiken innerhalb des Scrum Prozessrahmenwerks zu verbessern, um im kommenden Sprint effektiver und befriedigender arbeiten zu können

In jeder Sprint Retrospektive erarbeitet das Scrum-Team Wege zur Verbesserung der Produktqualität durch die entsprechende Anpassung der Prozesse oder der „DoD“ (Definition of Done), sofern diese Änderungen angemessen sind und nicht im Widerspruch mit Produkt- oder Unternehmensstandards stehen.

Zum Ende der Sprint Retrospektive sollte das Scrum-Team Verbesserungen für den kommenden Sprint identifiziert haben.

  • Die Umsetzung dieser Verbesserungen im nächsten Sprint ist die Anpassungsleistung zur Selbstüberprüfung des Scrum-Teams

Auch wenn jederzeit Verbesserungen eingeführt werden können, bietet die Sprint Retrospektive eine formelle Gelegenheit, sich auf die Überprüfung und Anpassung zu fokussieren

 

Scrum Artefakte

Die Artefakte von Scrum repräsentieren Arbeit oder Wert, um Transparenz sowie Möglichkeiten zur Überprüfung und Anpassung zu schaffen.

Die in Scrum definierten Artefakte wurden speziell so entworfen, dass sie die Transparenz der wesentlichen Informationen maximieren, um für alle ein gleiches Verständnis über das Artefakt zu schaffen

Der Product Backlog

  • ist eine Priorisierte Liste von Anforderungen in Form von Product Backlog Items – PBIs (User Stories und Epics)
    • Epics sind große User Stories und stehen weiter unten
  • Ist Dynamisch
    • wird kontinuierlich verfeinert und geändert
    • User Stories und Epics (Produkt Backlog Items) kommen dazu oder werden entfernt
    • wird immer wieder neu priorisiert
  • ist nach wert Priorisiert (absteigend)
  • Der Product Owner ist verantwortlich dafür

Der Sprint Backlog

  • Ist eine Priorisierte Liste der Arbeiten in einem Sprint
  • Enthält in Tasks (Aufgaben) heruntergebrochene User Stories
  • Visualisiert den Sprintfortschritt (z.B. in ein Burn Down Chart)
  • Hat Entwicklerteam als einziger Eigentümer
  • Tasks werden oft mittels eines Kanban Boards „WIP“ abgearbeitet

Das Inkrement

  • Das Inkrement ist das Ergebnis aus allen in einem Sprint fertiggestellten Product-Backlog-Einträgen und dem Resultat der Inkremente aller früheren Sprints
  • Am Ende eines Sprints muss das neue Inkrement fertig [„Done“] sein; das heißt es muss in einem verwendbaren Zustand sein und die Definition of Done des Teams erfüllen. Ein Inkrement ist ein Gegenstand inspizierbarer, fertiger [„Done“] Arbeit, der die Empirie am Ende des Sprints unterstützt
  • Das Inkrement ist ein Schritt in Richtung einer Vision oder eines Ziels (oder Releases). Es muss auch dann im einsatzfähigen Zustand sein, wenn der Product Owner es aktuell noch gar nicht ausliefern will