Alles was du über Scrum wissen musst

GehrigBesserer ist in ganz Deutschland unterwegs und unterstützt Unternehmer und Unternehmen dabei, Produkte zu realisieren und Projekte erfolgreich abzuschließen. Demgemäß sind wir maßgeblich als Scrum Master und Agile Coaches in der agilen Managementberatung tätig. In der Serie Scrum Basics bringen wir euch das Thema Scrum näher und veröffentlichen wöchentlich Artikel zum den verschiedenen Scrum Themen. Damit du nicht den Überlick verlierst, findest du hier alle Links zu den einzelnen Themen.

Was ist Scrum?

Scrum ist einfach zu verstehen, aber schwer zu meistern. Es ist keine Methodik, sondern ein Vorgehensmodell des Projekt- und Produktmanagements. Scrum wurde ursprünglich in der Softwaretechnik entwickelt, hat sich aber schnell darüber hinaus entwickelt. Entwickelt us dem Agilen Manifest beruht das Rahmenwerk auf 3 Säulen und 5 Werten. Im Kern gibt es 3 Rollen, 5 Events und 3 Artefakte, darüber hinaus aber noch viele Ergänzungen und Tools.

Das Agile Manifest [link]

Das Agile Manifest ist der Kern der agilen Bewegung. Es beinhaltet 4 Werte und 12 Prinzipien.

Inspect and Adapt [link]

In regelmäßigen Abständen reflektiert das Team, wie es effektiver werden kann und passt sein Verhalten entsprechend an – Agiles Manifest.

3 Säulen und 5 Scrum Werte [link]

Die drei Säulen Transparanz, Inspektion und Adaption treiben alle anderen Prozesse bei der Implementierung von Scrum. Die 5 Werte wurden erst im Juli 2016 dem Scrum Guide hinzugefügt. Natürlich sind die Werte Commitment, Mut, Fokus, Offenheit, Respekt Grundwerte und Qualitäten, die das Scrum-Framework von Anfang an untermauern und begleiten.

Scrum Rollen

Das Scrum Team besteht aus einem Scrum Master, einem Product Owner und dem Entwicklungsteam. Scrum Teams sind selbstorganisierend und funktionsübergreifend. Selbstorganisierende Teams entscheiden, wie sie ihre Arbeit am besten erledigen. Funktionsübergreifende Teams verfügen über alle notwendigen Kompetenzen, um die Arbeit ohne Abhängigkeit von Anderen durchzuführen. Das Teammodell in Scrum ist darauf ausgelegt, Flexibilität, Kreativität und Produktivität zu optimieren.

Scrum Master: verantwortlich ein Scrum Team und seine Umgebung zu führen, zu coachen, zu lehren und zu unterstützen, um Scrum richtig zu verstehen und zu nutzen. [link]

Product Owner: verantwortlich für die Maximierung des Wertes eines Produkts durch die Verwaltung und Darstellung der geschäftlichen und funktionalen Erwartungen. [link]

Entwicklungsteam: verantwortlich für die Verwaltung, Organisation und Durchführung aller Entwicklungsarbeiten zur Erstellung eines releasefähigen Produkts für jeden Sprint. [link]

Weitere Informationen:

Stakeholder: Personen außerhalb des Scrum-Teams mit einem spezifischen Interesse und Wissen über ein Produkt, das für die inkrementelle Entwicklung benötigt wird. Vertreten durch den Product Owner und aktiv im Scrum Team bei Sprint Reviews. [link]

Scrum Events

Um einen regelmäßigen Ablauf zu schaffen und den Bedarf an Meetings zu minimieren sind wenige Scrum Events vorgeschrieben. Alle Ereignisse sind timeboxed. Sobald ein Sprint beginnt, ist seine Dauer festgelegt und kann nicht verkürzt oder verlängert werden. Die übrigen Scrum Events können verkürzt werden, wenn ihr Zweck erreicht ist. So ist ein angemessener Zeitaufwand ohne Verschwendung im Prozess gewährleistet.

Sprint: Zeitlich begrenztes Event von 30 Tagen oder weniger. Dient somit als Rahmen für die anderen Scrum-Events und Aktivitäten. Sprints werden nacheinander, ohne Zwischenlücken durchgeführt. [link]

Sprint Planning 1+2: Zeitlich begrenztes Event von 8 Stunden oder weniger. Das Team überprüft die anstehenden Aufgaben aus dem Product Backlog, legt anschließend die nächsten Schritte fest und startet den Sprint. [link]

Sprint Review: Zeitlich begrenztes Event von 4 Stunden oder weniger. Abschluss der Entwicklungsarbeit eines Sprints. Dient dem Team und den Stakeholdern dazu, den Gesamtfortschritt des Produkts zu bewerten, um den Wert des nächsten Sprints zu maximieren. [link]

Sprint Retrospektive: Zeitlich begrenztes Event von 3 Stunden oder weniger, um einen Sprint zu beenden. Es dient dem Scrum Team dazu, den vergangenen Sprint zu reflektieren und Verbesserungen für den nächsten Sprint zu planen. [link]

Daily Scrum: Tägliches Zeitfenster von 15 Minuten oder weniger, in dem das Entwicklungsteam den nächsten Tag der Entwicklungsarbeit planen kann. Updates werden folglich im Sprint Backlog kenntlich gemacht. [link]

Weitere Informationen:

Product Backlog Refinement: die Aktivität in einem Sprint, durch die der Product Owner und das Entwicklungsteam die Granularität des Product Backlogs erhöhen. [link]

Schätzen: Das Entwicklerteam ist dafür verantwortlich, den Aufwand für die Implementierung von User Stories und anderen Items an denen sie arbeiten einzuschätzen. Oft wird hierzu Planning Poker und Value Monopoly gespielt [link].

Scrum Artefakte

Die von Scrum definierten Artefakte wurden speziell entwickelt, um die Transparenz der Aufgaben zu maximieren. Sie repräsentieren im Grunde genommen den Wert des Produkts und bieten eine Möglichkeit zur Überprüfung.

Product Backlog: eine geordnete Liste der Aufgaben, die zu erledigen sind, um ein Produkt zu schaffen, zu pflegen und zu erhalten. Verwaltet vom Product Owner. [link]

Sprint Backlog: Überblick über die Entwicklungsarbeit zur Realisierung eines Sprints. Eine Prognose der Funktionalität und der Arbeit, die erforderlich ist, um diese Funktionalität zu liefern. Verwaltet vom Entwicklungsteam. [link]

Product Inkrement: eine funktionierende Software, die zuvor erstellte Inkremente ergänzt. Die Summe aller Inkremente bildet ein Produkt. [link]

Weitere Informationen:

Impediment Backlog: eine Liste von Hindernissen, die das Team daran hindern effizient seine Aufgaben zu erledigen oder das Sprint Ziel zu erreichen [link]

User Stories: User Stories sind Teil des agilen Managements. User Stories sind kurze, einfache, prägnante Beschreibungen einer Funktion aus der Perspektive der Person, die die neue Fähigkeit wünscht [link]

Definition of Done: ein gemeinsames Verständnis der Erwartungen, die Software erfüllen muss, damit sie in das Produkt einfließen kann. Verwaltet vom Entwicklungsteam. [link]

Burn-down Chart/ Burn-up Chart:  Grafische Darstellung, die die Entwicklung der verbleibenden Aufgaben gegen die Zeit zeigt. [link]

Velocity: Kennzahl über die Anzahl der Product Backlog Items, die das Scrum Team während eines Sprints in ein Produkt umwandelt. [link]

Sonstiges

Kontinuierliche Integration, kontinuierliche Lieferung und kontinuierliche Bereitstellung: [link]

Test Driven Development (TDD) und Behavior Driven Development (BDD): Viele haben von Test Driven Development (TDD) sowie Behavior Driven Development (BDD) in Bezug auf die Softwareentwicklung gehört. Wir geben die Definitionen dieser beiden Praktiken sowie die wichtigsten Unterschiede. [link]

Lies hierzu auch den Scrum Guide, geschrieben und bereitgestellt von Ken Schwaber und Jeff Sutherland, Mitbegründer von Scrum.