Scrum ist ein stark evolutionäres Softwareprozessmodell-Rahmenwerk, das insbesondere durch die konsequente Organisation in kurze Zyklen und einem sich selbst organisierenden Team charakterisiert werden kann. Interessanterweise definiert Scrum keine Rollen oder Aktivitäten, die für das Software Engineering spezifisch sind, wie zum Beispiel IT-Architekt oder Programmierer. Genau genommen ist Scrum also eigentlich kein spezifisches Softwareprozessmodell-Rahmenwerk, sondern kann als Rahmenwerk für Prozessmodelle für ganz verschiedene Aufgaben eingesetzt werden.
Scrum definiert verschiedene Rollen, gibt strenge Vorgaben für Aktivitäten und deren Reihenfolge vor und führt Scrum-spezifische Elemente zur Verwaltung des Projektes ein.
In Scrum gibt es drei zentrale Rollen: den Product Owner, den Scrum Master und das Team.
Der Product Owner repräsentiert die Bedürfnisse des Kunden beziehungsweise des Anwenders. Er ist in Scrum sowohl für den Erfolg des Projekts als auch für das Requirements Engineering verantwortlich. Der Product Owner bildet die Brücke zwischen dem Projekt und der Außenwelt, denn er ist die einzige Schnittstelle zwischen Stakeholdern und Entwicklern des Systems. Wichtige fachliche Entscheidungen in Scrum werden durch den Product Owner getroffen. Er erstellt den Releaseplan, priorisiert die Anforderungen und nimmt das in einem Zyklus erstellte Ergebnis ab.
Das Team ist für die technische Konzeption, Konstruktion und Qualitätssicherung der Software verantwortlich. Ein Team arbeitet selbstorganisiert und autonom. In Abstimmung mit dem Product Owner bestimmt es selbst, wie viele Funktionen wann in einem Zyklus umgesetzt werden. Abgesehen von organisatorischen Vorgaben und Konventionen ist das Team frei in der Wahl der technischen Umsetzung. Alle zur Umsetzung eines Softwaresystems benötigten Rollen, zum Beispiel Architekt, Entwickler und Tester, arbeiten dafür in einem Team eng zusammen, wobei das Team insgesamt aus drei bis neun Personen besteht. Am Ende eines Zyklus präsentiert das Team das von ihm erzielte Ergebnis.
Der Scrum Master ist vergleichbar mit einem organisatorischen Projektleiter. Er moderiert und begleitet die Aktivitäten in Scrum und sorgt dafür, dass zeitliche und organisatorische Vorgaben in einem Scrumzyklus von allen Beteiligten eingehalten werden. Darüber hinaus sorgt er für eine möglichst ideale Arbeitsumgebung von Product Owner und Team, in dem er die Hindernisse aus dem Weg räumt, die ein reibungsloses Arbeiten behindern. Dabei hat der Scrum Master keine Weisungsbefugnis gegenüber dem Product Owner oder dem Team. Er soll stattdessen den Scrumprozess managen, indem er das Entwicklungsteam und den Product Owner zur Arbeit befähigt und vor äußeren Einflüssen und Störungen beschützt.
Die wichtigsten Konzepte, die in einem Scrumprozess eingesetzt werden, sind das Product Backlog, das Sprint Backlog und die Velocity.
Das Product Backlog ist eine Liste aller Anforderungen an das System. Die Detaillierung der Anforderungen reicht dabei von einer ersten Idee bis hin zu einer vollständig spezifizierten Funktion. Zu Beginn eines Softwareprojektes enthält das Product Backlog oft nur wenige, grob umrissene Anforderungen und Wünsche an das System. Im Verlauf des Prozesses werden die Anforderungen vom Product Owner verfeinert, ergänzt und priorisiert. Nur der Product Owner darf Änderungen am Product Backlog vornehmen.
Das Sprint Backlog ist eine Liste von Anforderungen, die in einem sogenannten Sprint (in Scrum wird ein Zyklus "Sprint" genannt) vom Team umgesetzt werden sollen. Der Sprint Backlog ist eine Teilmenge des Product Backlog. Welche Anforderungen in das Sprint Backlog kommen, vereinbaren Product Owner und Team miteinander. Die Menge der Anforderungen ist dabei abhängig von der Velocity des Teams. Während der Bearbeitungszeit eines Zyklus wird der Sprint Backlog nicht verändert.
Die Velocity eines Teams ist eine teamspezifische Kennzahl, die sich aus Menge und Umfang der von einem Team in einem Zyklus umgesetzten Funktionen ergibt. Typischerweise stabilisiert sich die Velocity eines Teams mit den Erfahrungen nach den ersten 5-7 vom Team durchgeführten Zyklen. Die Velocity bildet einen Anhaltspunkt dafür, wie viele und welche Anforderungen ein Team sich für die Dauer eines Zyklus aus dem Product Backlog in ein Sprint Backlog laden kann.
Die allgemeine Struktur von Scrum ist in der folgenden Abbildung dargestellt. Aus dem Product Backlog wird für jeden Sprint das
Sprint Backlog erstellt. Anschließend setzt das Team während eines Sprints, der beispielsweise 30 Tage dauern kann, die Anforderungen
aus dem Sprint Backlog um. Dabei findet jeden Tag eine kurze Statusbesprechung statt, in der jedes Teammitglied kurz vorstellt, was es in
den vergangenen 24 Stunden gemacht hat, welche Probleme es dabei gab und was es in den kommenden 24 Stunden machen wird. Die tägliche
Besprechung heißt Daily Scrum oder auch Standup Meeting und darf maximal 15 Minuten dauern. Am Ende eines Sprints stellt das Team die um
weitere Funktionen erweiterte Software vor und bestimmt die Liste der Anforderungen für den nächsten Zyklus.
In Scrum ist genau festgelegt, aus welchen einzelnen Phasen ein Zyklus besteht und welche Rollen dort welche Aktivitäten durchführen. Ein Sprint lässt sich, wie in folgender Abbildung illustriert, in vier verschiedene Phasen aufteilen:
In der Phase Sprint Planning stellt der Product Owner die Anforderungen vor, die er für den aktuellen Sprint vorgesehen hat. Daraufhin schätzt das Team den Umsetzungsaufwand für jede der Anforderungen. Anschließend wird das Sprint Backlog befüllt. Dazu wählt das Team entsprechend die vom Product Owner am höchsten priorisierten Anforderungen aus, sodass der summierte Aufwand aller Anforderungen im Sprint Backlog der Velocity des Teams entspricht. Anschließend plant das Team intern, wie die Anforderungen umgesetzt werden und wer für welche Anforderungen verantwortlich ist.
Während der Sprint Durchführung setzt das Team die Anforderungen aus dem Sprint Backlog um. Der Product Owner steht dabei für Fragen zur Verfügung. Hauptsächlich spezifiziert der Product Owner während der Durchführung die Anforderungen für den nächsten Sprint (Zyklus). Die Menge der Anforderungen im Sprint Backlog wird im Verlauf eines Sprints nicht verändert. Der Scrum Master beseitigt Hindernisse, die bei der Durchführung auftreten, und sorgt für die ordnungsgemäße Durchführung des täglichen Standup Meetings.
Im Sprint Review präsentiert das Team sein Ergebnis vor den Stakeholdern. Die Stakeholder geben ihr Feedback zum Ergebnis. Der Product Owner nimmt das Sprintergebnis offiziell ab und dokumentiert Änderungen sowie noch nicht umgesetzte Anforderungen im Product Backlog.
Als letzte Phase im Sprint wird eine Sprint Retrospektive durchgeführt. Product Owner, Team und Scrum Master reflektieren gemeinsam
den eigenen Arbeitsprozess des Sprints unter den Gesichtspunkten "Was lief gut?" und "Was muss verbessert werden?".
