Einer der Werte im agilen Manifest lautet:

Funktionierende Software steht über einer umfassenden Dokumentation!

Scrum ist eine agile Methode des Projektmanagements, die sich hervorragend für die Entwicklung von Softwareprojekten eignet. Ein Scrum Projekt läuft in Iterationen ab, die Sprints genannt werden. Es gibt feste Rollen für die Mitwirkenden: Development Team, Product Owner und Scrum Master. Sie bilden das Scrum Team.

Das Ziel

Das PSI - das potential shipable increment (rechts in der obigen Grafik) steht für das Ergebnis des Scrum Prozesses: das Stück Software, das dem Kunden ausgeliefert, sprich in Produktion genommen werden kann. Es ist dann bereits getestet und ablauffähig.

Das PSI wird vom Development Team während eines Sprints erstellt (siehe Grafik-Mitte). Die Mitglieder des Development Teams werden alle als Entwickler (Developer) bezeichnet, unabhängig davon, welche Aufgaben sie tatsächlich erfüllen. Ein Entwickler-Team (Development Team) ist cross-funktional ausgestattet, d.h., es sind alle erforderlichen Skills vertreten, um das agile Projekt erfolgreich durchzuführen.

Ein Sprint umfasst einen Zeitraum von 2-4 Wochen, SMK bevorzugt 2 Wochen. In dieser Zeit implementiert das Team das PSI, testet, dokumentiert, führt ein oder mehrere Reviews durch und legt es schließlich dem Product Owner(siehe Grafik links oben) zur Abnahme vor. Dieser ist verantwortlich für die Planung, den Kontakt zum Kunden und für die sogenannten User Stories.

Die Bearbeitung der Kundenanforderungen als User Stories

Die Kundenanforderungen für die Software bezeichnet man als User Stories. Sie werden vom Product Owner in enger Zusammenarbeit mit dem Kunden formuliert und in einer Liste festgehalten, dem Product Backlog. User Stories können unterschiedliche Anforderungen beschreiben. Der Product Owner verwaltet diese Liste, nur er darf Veränderungen daran vornehmen. Er sortiert die User Stories innerhalb der Liste nach Prioritäten. Die wichtigste User Story ist die, deren Realisierung den größten Mehrwert für den Kunden bringt; sie steht deshalb ganz oben.

Die Anzahl der User Stories hängt von verschiedenen Faktoren ab:

  • Die zur Verfügung stehende Kapazität. Dazu gehören die Anzahl der Entwickler im Team, ihre Verfügbarkeit während des Sprints und ihre individuellen Skills.
  • Komplexität und Umfang der einzelnen User Stories. Sie werden während eines RefinementMeetings analysiert und geschätzt (s. u.).
  • Know-how der Entwickler

 

Ablauf eines Sprints

Zu Beginn eines jeden Sprints trifft sich das gesamte Team zum Sprint Planning. Hier wird festgelegt, welche der User Stories jetzt vom Development Team realisiert werden.

Zusammen mit dem Scrum Master und Product Owner bespricht das Development Team die Inhalte der infrage kommenden User Stories. Unter Berücksichtigung der Kapazität, der Komplexität der User Stories und dem Know-how der Entwickler (siehe oben) wird festgelegt, wie viele der geplanten User Stories im anstehenden Sprint bearbeitet werden. Das Team gibt ein Commitment ab: Es sagt zu, dass die ausgewählten User Stories tatsächlich während des Sprints realisiert werden. Das erhöht die Planungssicherheit und die Aussagefähigkeit des Product Owners gegenüber dem Kunden. Das Ergebnis wird in dem Sprint Backlog (siehe Grafik, linke Spalte des Task Boards (Überschrift 'St') festgehalten.

Im Daily Scrum Meeting (siehe Grafik-Mitte) werden täglich Informationen ausgetauscht. Es findet im Stehen statt und jedes Teammitglied, auch Product Owner und Scrum Master, beantworten reihum diese 3 Fragen: 1. Was habe ich seit dem letzten Daily Scrum erreicht? 2. Was plane ich bis zum nächsten Daily Scrum? 3. Was behindert mich bei der Arbeit?

Diese sogenannten Impediments, also die Hindernisse, sind eine wichtige Information für den Scrum Master. Eine seiner Aufgaben ist es, diese Hindernisse zu beseitigen.

Im Backlog Refinement Meeting (siehe Grafik ganz rechts) werden die für die nächsten beiden Sprints infrage kommenden User Stories analysiert. Zu diesem Zweck geht der Product Owner zusammen mit dem Development Team und dem Scrum Master der Reihe nach die einzelnen User Stories im Product Backlog durch. Man stellt gemeinsam fest, ob alle Voraussetzungen für die Realisierung der User Stories vorliegen. Diese Voraussetzungen werden auch als Definition of Ready (siehe Grafik links unten) bezeichnet. Die DoR existiert oft als Checkliste.

Auch wenn die DoR erfüllt ist, gibt es möglicherweise andere offene fachliche Fragen, die ebenfalls in dem Meeting geklärt werden. Anschließend wird die anstehende User Story geschätzt. Es gibt verschiedene Vorgehensweisen beim Schätzen, die hier erläutert sind. Ziel der Schätzung ist es, eine Vorstellung zu bekommen, wie die einzelnen User Stories relativ zu einander taxiert werden müssen. Für die Schätzung spielen verschiedene Faktoren eine Rolle; ausgehend von der Komplexität einer User Story und ihrer Relation zu den anderen wird der Aufwand geschätzt.

Die Schätzung wird als Punktevergabe, Storypoints genannt, abgegeben. Jede User Story erhält eine bestimmte Punktzahl. Wichtig: Die Schätzung wird von dem Scrum Team gemeinsam durchgeführt. Sie ist eine der Grundlagen für das Commitment des Development Teams zu Beginn des nächsten Sprints.

Der Product Owner legt mit Unterstützung des Scrum Masters eine Liste von Kriterien fest, die erfüllt sein müssen, damit eine User Story als erledigt betrachtet werden kann: Definition of Done (siehe Grafik links unten). Die Abnahme liegt in der Verantwortung des Product Owners, der die Kundenanforderungen am besten kennt. In jeder Organisation gibt es unterschiedliche Kriterien, die erfüllt werden müssen, z. B. dass die Software bestimmten Leistungsmerkmalen entsprechen muss oder dass ein Testnachweis für die Software erstellt wurde.

 

In der Sprint Retrospektive (kurz Retro) setzt sich das Team zusammen und bespricht, was im letzten Sprint nicht so gut gelaufen ist. Für das Selbstbewusstsein der Teams ist es zentral, dass es festhält, was gut gelaufen ist. Der Scrum Master spielt hier eine wichtige Rolle und achtet darauf, dass dieser Aspekt genauso gewichtet wird, wie die Fehler, Probleme und Befindlichkeiten, die im Rückblick besprochen werden.

In der Retro geht es um den Aspekt der ständigen Verbesserung. Das Resultat sind Maßnahmen, die während der nächsten Sprints angewendet werden. Es ist eine Form der Selbst-Verbesserung, niemand darf hier von außen Druck ausüben. Der Scrum Master wehrt solche äußeren Einflüsse ab.

Das PSI wird dem Kunden während des Review Meetings vorgestellt und er wird gebeten, sein Feedback zu geben (siehe Grafik rechts). Während dieses Review Meetings demonstriert das Scrum Team dem Kunden, was aus seinen Anforderungen, den User Stories, entstanden ist. Diese Meetings mit dem Kunden haben eine zentrale Funktion in der Scrum Methodik. So kann eine klein- und feinschrittige Abstimmung mit dem Kunden und seinen Wünschen erfolgen.

Die Aufgaben des Scrum Masters

Der Scrum Master sorgt dafür, dass innere und äußere Hindernisse und negative Einflüsse beiseite geräumt bzw. ausgeschaltet werden. Er ist verantwortlich für die Motivation des Scrum Teams. Noch bevor das Team mit seiner Projektarbeit beginnt, klärt der Scrum Master, ob vor dem Start alle notwendigen Voraussetzungen erfüllt sind. Es muss bereits ein Product Backlog existieren, auch sollten einige User Stories festgelegt sein, die im ersten Sprint bearbeitet werden können. Zu den vorbereitenden Schritten gehört auch, dass die technische Infrastruktur zur Verfügung steht: Rechner, Tools, Netzwerkverbindungen, Task Boards, Flipcharts, Stellwände, Stifte, Lineale, Kalender, Schreibtische, Zugangsberechtigungen usw.

Bei Scrum steht der Teamgedanke an oberster Stelle. Die Entwickler müssen sich zusammenfinden und sich blind aufeinander verlassen können. Gerade bei neu zusammengestellten Teams benötigt dies eine gewisse Zeit. Die Teams durchlaufen verschiedene typische Stadien: Forming, Storming, Norming, Performing. Letzteres heißt, dass sich das Team zu einer leistungsfähigen Einheit zusammengefunden hat. Gelingt dies, ist es unschlagbar. Der Weg bis dahin kann - muss aber nicht - steinig sein. Er wird vom Scrum Master begleitet und geleitet.

Scrum Teams sind in der Regel hoch motiviert und möchten sofort mit ihrer Arbeit beginnen.