Scrum in der Nussschale

Was ist Scrum? und FAQ

Sie wollen eine kurze prägnante Einführung zu Scrum? Die beste Lektüre zu Scrum ist der ScrumGuide der von den Erfindern von Scrum Dr. Jeff Sutherland und Ken Schwaber verfasst und gepflegt wird. Ergänzend lesen Sie doch hier ein paar Informationen zu Scrum.

Kurze Zusammenfassung „was ist Scrum“

Scrum ist ein einfaches Projektmanagement- bzw. Produkterstellungs-Framework, in das Entwicklungsteams selbstbestimmt erprobte Praktiken einbetten.
Der Rahmen sieht einen empirisch, iterativen Prozess vor, bei dem in konstanten Zeitabschnitten (Iterationen) von bis zu einem Kalendermonat (30 Tagen) ein fertiggestellter Produktstand (Product Increment) dem Kunden zur Inspektion bereitgestellt wird. Termine sind nicht verschiebbar, sondern die Menge an Features, die in einer Zeitbox vollständig als „fertig“ vermerkt werden können, variiert. Da die Iterationen, sogenannte Sprints, immer gleich lang sind, entwickelt das Development-Team über die Zeit ein Gefühl und Statistiken darüber, wie viele Arbeitseinheiten es in einem Sprint erledigen kann. Damit wird die Planung in einem Team immer verlässlicher.
Scrum verfolgt einen evolutionären Ansatz. Vor jedem Sprint werden neue Prioritäten gesetzt und das Gelernte miteinbezogen.
Das schafft Flexibilität in einer sich schnell wandelnden globalen Welt. Es ermöglicht dem Kunden den größten möglichen Wert, für seine Investitionen, zu bekommen.
Sich Teams entwickeln die höchste Produktivität, in der die Summe aller Teile mehr ergibt, als jeder Einzelne. Scrum stellt Rahmenwerk mit Prozessen und Methoden zur Verfügung, um Selbstorganisation zu organisieren.

Scrum Rollen

Scrum sieht drei Rollen vor:

  • Development Team oder kurz Team
  • Scrum Product Owner
  • Scrum Master

Alle drei Rollen zusammen werden als Scrum-Team bezeichnet. Alle anderen Rollen werden pauschal als Stakeholder bezeichnet.

Scrum Master

Er dient dem Team als Scrum-Lehrer, Scrum-Coach, Mentor und Moderator und sorgt dafür, dass die Scrum Regeln beachtet werden. Er trägt die Verantwortung dass so genannte Impediments (Stolpersteine, Hindernisse) „aus dem Weg geräumt“ werden und vermittelt zwischen Team und der Organisation (Managern). Das Hautpziel eines ScrumMasters ist „continous Improvement“! (bezogen auf Scrum Team, Development Team und Organisation). Schulungen zum ScrumMaster finden Sie hier.

Scrum Development Team

Dies sind alle Personen die direkt an der Erstellung des Produkts beteiligt sind. Es schließt Programmierer, Softwarearchitekten, Tester, Systemadministratoren, Technische Redakteure und allle weiteren im Entwicklungsprozess benötigen Personen ein.
Letzt Endlich sind alle „Skills“ auf dem Team vertreten, die für die Erstellung des Produktes benötigt werden. Man spricht hier auch von „Cross Funktionalität“ auf dem Team. Die zweite wichtige Eigenschaft eines Development Teams ist die „Selbst-Organisation“. Sprich niemand im oder ausserhalb des Teams gibt Vorgaben wie oder von wem gewisse Aufgaben zu erledigen sind. Schulungen zum Development Team (Member) finden Sie hier.

Scrum Product Owner

Es ist der Fachvertreter und zuständig, dass Produkte den höchsten „Nutzwert“ enthalten. Sprich der Product Owner verantwortet den Kundennutzen. Man spricht in diesem Zusammenhang auch vom „Value Maximizer“. Er liefert die Anforderungen und sorgt für einen möglichst hohen ROI und geringen TCO. Schulungen zum Scrum Product Owner finden Sie hier.

Scrum Artefakte

Der Scrum Guide schlägt folgende Artefakte zur Steuerung vor:

  • Product Backlog
  • Sprint Backlog
  • Product Increment

Product Backlog

Ausgehend von der gemeinsamen Vision für das Produkt erstellt der Scrum Product Owner häufig in Zusammenarbeit mit den Stakeholdern eine Liste mit allen Anforderungswünschen für das Produkt/Projekt.
Einzelne Produkt Backlog Items, meist User Stories, beschreiben diese Anforderungen aus Sicht des Kunden und in der Sprache des Kunden.
Die Liste aller für das Produkt/Projekt zu erledigen Backlog Items ergeben den Product Backlog.
Der Scrum Product Owner hat die Hoheit über das Product Backlog.

Eigenschaften des Product Backlogs

  • Das Product Backlog ist eine geordnete Liste mit einer eindeutigen Reihenfolge.
  • Die Reihenfolge legt der Scrum Product Owner fest. Ein wichtiger Einflussfaktor ist der „Business Value“ der Backlog Items.
  • Das Product Backlog soll geschäzt sein (am besten nach Value und Größe der Backlog Items).
  • Das Product Backlog ist nie „Vollständig“. Es ist ein „lebendes“ „emergentes“ Artefakt. Dies bedeutet auch, dass das Product Backlog vom Scrum Product Owner umsortiert werden kann.
  • Das Product Backlog spiegelt das zu entsehende Produkt wieder.

Sprint Backlog

Das Sprint Backlog ist ebenfalls eine Liste. Es macht die Arbeit sichtbar, die das Team in einem Sprint erledigt. Es enthält alle Product Backlog Items, die in diesem Sprint bearbeitet werden und die dazugehörigen heruntergebrochenen Einzelaufgaben.
Das Sprint Backlog wird während des Sprint Plannings erstellt. Neue Aufgaben (aber keine neuen Anforderungen) können jederzeit ergänzt werden.
Das Sprint Backlog ist ein Arbeitsmittel des Development Teams und deshalb hat auch das Development Team die Hoheit über das Sprint Backlog.

Product Increment

(engl. Potentially shippable (Product) Increment): Teilergebnis des Projekts, das pro Sprint geliefert wird.

Das Resultat am Ende des Sprints ist ein potenziell auslieferbares Produkt. Die Funktionalität des Ergebnisses wächst stückchenweise (inkrementell). Deswegen sprechen wir von einem Produktinkrement. Das Inkrement enthält das Ergebnis aller umgesetzten Product Backlog Einträge.
Das Entwicklungsteam arbeitet immer so, dass es das Product Increment ausliefern könnte. Ob es tatsächlich ausgeliefert wird, entscheidet der Product Owner.
Die Schwierigkeit gerade für neue Scrum-Teams ist, im Planning ein sinnvolles Inkrement zu definieren.

Scrum Meetings / Scrum Aktivitäten / Scrum Ceremonies

Bei Scrum arbeiten wir in kurzen Zyklen, den Sprints, damit wir uns immer wieder Feedback holen und verbessern. Zur Koordination kennt Scrum folgende Ereignisse:

  • Sprint
  • Sprint Planning
  • Daily Scrum
  • Sprint Review
  • Sprint Retrospektive

Sprint

Scrum Produktentwicklung (bzw. Scrum-Projekte) schreiten in Serien von Sprints voran. Zu Beginn wird die anstehende Arbeit gemeinsam geplant. Das Produkt wird während des Sprints entworfen, kodiert und getestet.
Am Ende des Sprints wird immer ein potenziell auslieferbares Produktinkrement (PSI) übergeben. Während des Sprints überprüft das Team täglich im Daily Scrum, ob es das Sprintziel noch erreichen kann.
Eine konstante Dauer führt zu einem besseren Rhythmus. Das bedeutet, dass ein Sprint nicht verkürzt oder verlängert wird. Die Sprintlänge wird nicht von Sprint zu Sprint geändert.
Die Sprintlänge sollte so gewählt werden, dass der Product Owner angemessen mit Risiken umgehen kann (höheres Risiko = kürzere Sprintlänge) und dass er sich mit den anderen geschäftlichen Ereignissen im Unternehmen synchronisieren kann.
Die maximale Sprintlänge lt. Scrum Guide liegt bei 4 Wochen bzw. ein Kalendermonat.

Sprint Planning

Im Sprint Planning stellt der PO die Anforderungen vor und das Team plant. Es geht um zwei Themen. Die Planung dauert (bei einem vierwöchigen Sprint) max. 8 Stunden:

  • Punkt 1: Der PO stellt dem Team die Anforderungen vor. Das Team stellt Fragen, damit es die Anforderungen gut versteht. Gemeinsam wird ein Sprintziel (Sprint Goal) entwickelt. Das Team gibt am Ende von Teil 1 eine Abschätzung (Forecast) ab, was es schaffen wird.
  • Für Punkt 2 bespricht das Team, wie es die Anforderungen konkret umsetzt und was dafür genau zu tun ist. Einzelne Backlog Items werden für das Sprint Backlog verfeinert und zu umsetzbaren Arbeitseinheiten (Tasks) geschnitten. Somit baut das Development Team sukzessive das Sprint Backlog auf.

Daily Scrum

Während des Sprints prüft das Team täglich, ob es das Sprintziel erreicht.
Alle sind eingeladen. Aber nur Team-Mitglieder und der Scrum Master dürfen reden. Der Scrum Product Owner steht idealer Weise für Fragen optional bereit. Das Daily ist kein Statusberichte für den Scrum Master oder Scrum Product Owner. Es dient dem Team zur Synchronisation:

  • Was habe ich gestern fertig gestellt um das gemeinsamme Sprint Ziel zu erreichen?
  • Was will ich heute fertig stellen um das gemeinsamme Sprint Ziel zu erreichen?
  • Hindert mich etwas an der Fertigstellung?

Es ist kein Meeting zur Problemlösung. Es hilft dabei, andere Meetings zu vermeiden.
Das Daily findet immer zur gleichen Zeit, am gleichen Ort statt. Der Scrum Guide sieht für das Daily eine maximale  Zeitdauer von 15 Minuten (unabhängig von Teamgröße und Sprintlänge) vor.

Sprint Review

Im Review stellt das Development Team dem Product Owner ein potenziell auslieferbares Produkt vor. Das Development Team erhält idealer Weise direktes Feedback von den Stakeholdern.
Der Product Owner akzeptiert umgesetzte Product Backlog Items oder weist diese zurück.
Erkenntnisse aus dem Scrum Review Meeting fließen in den nächsten Sprint ein. Das bedeutet, dass die Architektur, bestimmte Designs oder Lösungsansätze bestätigt oder abgelehnt werden. Der Product Owner überdenkt eventuell in diesem Meeting die Priorisierung des Product Backlogs (durch Input und Impulse der Stakeholder), denn offiziell gibt es zwischen Sprint Retrospektive und dem nächsten Sprint Planning keine Zeit dafür.
Der Scrum Guide sieht für das Review Meeting eine maximale Zeitdauer von 4 Stunden (Üblicher Weise bezogen auf eine Sprintlänge von 4 Wochen) vor.

Sprint Retrospektive

Die Retrospektive ist ein bewusster Haltepunkt am Ende des Sprints, damit das Scrum Team sich Zeit für Verbesserungen nimmt. Sie ist DAS Meeting des Scrum Masters. Es werden sowohl positive als auch negative Dinge besprochen.
Es ist gut, mit der Auflistung der Dinge zu starten, die das Scrum Team schon gut hinbekommen hat. Das gibt Energie.
Esther Derby und Diana Larsen schlagen folgenden Ablauf vor:

  • Türöffner
  • Daten sammeln
  • Gruppieren
  • Einsichten generieren
  • Entscheidungen treffen
  • Abschluss

Das Team beschließt 1-2 Verbesserungsmaßnahmen für den nächsten Sprint.
Der Scrum Guide sieht für die Retrospektive eine maximale Zeitdauer von 3 Stunden (bezogen auf eine Sprintlänge von 4 Wochen) vor.

Timebox

Alle Scrum-Meetings haben eine feste Dauer (Timebox). Die bewusste zeitliche Beschränkung hilft dabei, zügig zu arbeiten und zu fokusieren. Scrum Master und Team achten auf das Einhalten der Timeboxen.

 

Advertisements