Der Scrum Prozess

Die Bestandteile des Scrum Prozesses lassen sich unterteilen in Ereignisse, Beteiligte und Ergebnisse (Artefakte). Außerdem wird explizit auf die Transparenz der Artefakte eingegangen. Ausführlich lässt sich das im Scrum Guide oder der Aufbereitung von Agile Atlas nachlesen. Im Folgenden haben wir diese kurz zusammengefasst.

• Ereignisse im Scrum Prozess
• Ergebnisse (Artefakte) im Scrum Prozess
• Beteiligte am Scrum Prozess
• Tranzparenz der Artefakte im Scrum Prozess

Scrum gibt Orientierung, doch lässt vieles offen. Bei Taktsoft haben wir einige Aspekte noch enger gefasst und machen über Scrum hinaus Vorgaben, die Teil unseres Agilen Prozesses sind.

Es existieren sechs unterschiedliche, wiederkehrende Ereignisse in Scrum Projekten:

Sprint

Der Sprint ist das das übergeordnete Ereignis im Scrum Prozess. Alle im Folgenden beschriebenen Ereignisse sind entsprechend Bestandteile eines Sprints. Ein Sprint ist eine Iterationsschleife eines Projekt-Teams im Scrum Prozess und sollte zwischen 2 und 4 Wochen dauern. Das Ziel eines Sprints ist in Form von konkret vorliegenden Aufgaben (den Backlog Items im Sprint Backlog) klar definiert. Die Möglichkeiten von außen in einen Sprint einzugreifen sind stark eingeschränkt. Der Product Owner hat die Möglichkeit bei neuen Erkenntnissen den Anforderungsumfang gemeinsam mit dem Team anzupassen, doch ändern sich die Vorzeichen stark, wird im Zweifel empfohlen einen Sprint abzubrechen. Die Zeit eines Sprints im Scrum Prozess dient insbesondere dem Entwicklerteam als sicherer Hafen für möglichst konzentriertes Entwickeln der Software, weitgehend abgeschirmt von allen störenden Einflüssen.

Sprint Planning

Das Sprint Planning dient im Scrum Prozess der Planung des kommenden Sprints. Auf Basis des aktuellen Entwicklungsstandes der Software (dem Inkrement), den vom Product Owner priorisierten Anforderungen (aus dem Product Backlog), der zur Verfügung stehenden Entwicklerkapazität und der Erfahrung aus den bisherigen Sprints (der bisherigen Entwicklungsgeschwindigkeit) werden durch das Entwicklerteam die realisierbaren Product Backlog Einträge für den anstehenden Sprint bestimmt. Das gesamte Scrum Team einigt sich daraufhin auf das Ziel für den anstehenden Sprint. Das Ergebnis ist das Sprint Backlog. Im Scrum Prozess bestimmt dann das Entwicklerteam eigenständig über die Art und Weise der Zielerreichung. Das heißt zum Beispiel, dass die technische Umsetzung vollständig in der Hoheit des Entwickler-Teams liegt und die einzelnen Aufgaben autonom vergeben werden. Der Product Owner dient im Folgenden und während der Zeit eines Sprints vor allen Dingen als fachlicher Ansprechpartner bei auftretenden Fragen.

Daily Scrum

Das Daily Scrum dient dem Entwicklerteam im Scrum Prozess als täglicher, eng begrenzter Zeitraum zum Austausch aktueller Informationen den vergangenen und kommenden Tag betreffend. Er findet zu einer fest definierten Zeit auf klar definierte Weise statt. Aktive Teilnehmer sind grundsätzlich die Mitglieder des Scrumteams. Dieser Termin dient nicht dazu, alle aktuellen Probleme in Gänze zu klären, sondern dem knappen Informationsaustausch zum aktuellen Stand und akuten Hindernissen des Entwicklerteams im Scrum Prozess. Alles Weitere kann anschließend, Themen-abhängig, in kleinerer Runde abgestimmt werden.

Sprint Review

Das Sprint Review dient am Ende eines Sprints der Überprüfung des aktuellen Inkrements und dem Voranschreiten des Projektes. Auch wenn Projekt-Beteiligte im Scrum Prozess generell dazu eingeladen sind an Meetings teilzunehmen und sich mit dem Backlog und dem aktuellen Stand der Software auseinander zu setzen, so ist das der Termin im Scrum Prozess, den man interessierten Stakeholdern nur ans Herz legen kann: Das ist der regelmäßige Moment zu dem das Entwicklerteam die aktuellsten Ergebnisse präsentiert und bereits die darauf folgenden Todos diskutiert. Darüber hinaus werden das Produkt-Umfeld und mögliche Veränderungen betrachtet, die Auswirkungen auf das Projekt haben, die womöglich Anpassungen im Product Backlog und somit im weiteren Vorgehen nach sich ziehen. Der Blick auf Zeitplan und Budget runden das Sprint Review ab.

Sprint Retrospective

Die Sprint Retrospective dient der innen gerichteten Überprüfung des Scrum-Teams. Hier geht es darum, die am Scrum Prozess beteiligten Menschen, Beziehungen, Prozesse und Werkzeuge zu betrachten, Gutes (insbesondere in Abgrenzung zu vergangenen Retrospektiven) heraus zu heben und Probleme anzusprechen. Der größte Teil des Meetings wird dann darauf verwendet, einen Plan zur Umsetzung von Verbesserungen und Lösungsmöglichkeiten zu erarbeiten.

Refinement

Refinement, ursprünglich Backlog-Grooming genannt, dient zur inhaltlichen Auseinandersetzung mit den Anforderungen. Neben der Verfeinerung der einzelnen Backlog Items findet in diesem Zusammenhang auch eine Bewertung durch die Entwickler und eine Priorisierung statt. Das Ergebnis ist die Grundlage für Entscheidungen im Rahmen der kommenden Sprint Plannings und für das mittelfristige weitere Vorgehen im Scrum Prozess. Daher kann es sein, dass bis zu 10% der gesamten Entwicklerteam-Kapazität im Scrum Prozess darauf verwendet werden muss. Die Schätzung der Komplexität der einzelnen Einträge liegt in der Hoheit des Entwicklerteams. Das Team kann dabei zwar unterstützt werden, seine Aussage ist jedoch nicht zu kompromittieren. Für die Priorisierung der inhaltlichen Ausgestaltung ist im Scrum Prozess hingegen der Product Owner verantwortlich. Ein intensiver Informationsaustausch zu den einzelnen Backlog-Items zur Steigerung des Verständnisses und zur Vorbereitung eines jeden Sprint Plannings ist zwischen diesen beiden Polen zwingend erforderlich.

Artefakte sind greifbare Resultate der oben stehenden Ereignisse.

Inkrement

Das wichtigste gefertigte Ergebnis (sprich Artefakt) im Scrum Prozess und das ursprüngliche Ziel einer jeden Softwareentwicklung ist das sogenannte Inkrement. Das Inkrement ist der aktuelle Stand der Software auf seinem Weg zum fertigen Produkt. Es ist (daher der Name) die schrittweise Erhöhung der funktionsfähigen Software mit jeder Iteration. Scrum geht sogar noch einen Schritt weiter und definiert dieses Inkrement als "potentially shipable". Dies bedeutet: Die Software ist im Scrum Prozess zu jeder Zeit mit all ihren, bis zu diesem Zeitpunkt erlangten Features und Eigenschaften, einsetzbar und somit von Projektbeteiligten und Interessensvertretern einsehbar, testbar und beurteilbar. Es wird also beständig und messbar Wert geschaffen.

Product Backlog

Das Product Backlog ist im Scrum Prozess eine priorisierte Liste von allem, was an Aufgaben für das Ziel-Produkt zu erledigen ist. Es dient als alleinige Anforderungsquelle für Anpassungen an der Software und steht unter der Hoheit des Product Owners. Das Product Backlog entwickelt sich ständig weiter. Während zu Beginn des Projekts die meisten Einträge darin womöglich nur rudimentär ausfallen, und nur die wichtigsten Features und Grundlagen genau beschrieben sind, entwickelt sich die Detailhöhe und die Breite ständig weiter. Dem Product Backlog kommen dabei im Scrum Prozess zwei wesentliche Aufgaben zu: Es gibt dem Entwicklerteam Informationen für die Umsetzung und dient dem Product Owner als Grundlage bei der Priorisierung und Kommunikation mit Stakeholdern.

Sprint Backlog

Im Scrum Prozess stellt das Sprint Backlog den Ausschnitt des Product Backlogs für den aktuellen Sprint dar. Darüber hinaus beinhaltet es den Plan, wie die darin enthaltenen Einträge umgesetzt werden. Das Ergebnis des Sprint Plannings wird vom gesamten Scrum Team verabschiedet und ist die Grundlage für den anstehenden Sprint. Es darf während des Sprints zwar weiter verfeinert, aber nicht in seinem Umfang oder seiner Zielsetzung geändert werden. Das Scrum-Team muss sich am Ende eines Sprints an den Zielen des Sprint Backlogs messen lassen.

Das Scrum Team besteht aus Menschen, die eine der drei folgenden Rollen einnehmen. Das Scrum Team arbeitet als eigenständige und selbstorganisierte Einheit interdisziplinär.

Product Owner

Der Product Owner ist im Scrum Prozess verantwortlich für die inhaltliche Ausrichtung des Projektes. Er kontrolliert das Product Backlog und legt die Prioritäten der Backlog Einträge fest. Er ist die Schnittstelle zum Projekt-Umfeld und den übrigen Stakeholdern, also insbesondere dem Kunden. Den größten Teil der Zeit befasst er sich damit, Anforderungen in User Stories zu übersetzen und zu verfeinern: Einerseits durch kontinuierliches Refinement des Product Backlogs in Zusammenarbeit mit dem Entwicklerteam, andererseits durch Rücksprachen und Informationstransfer in Richtung der übrigen Stakeholder.

Entwickler

Der Entwickler ist Teil des Entwicklerteams, welches alleinig verantwortlich für die Erstellung des Produkt-Inkrements ist. Für die Lösung dieser Aufgabe besitzt dieses Team alle notwendigen Fähigkeiten und organisiert sich dabei selbständig. Im Scrum Prozess steht das Team als Ganzes in der Verantwortung für die Ziele, die es sich selbst setzt. Das Entwicklerteam soll ca. 3-9 Mitglieder umfassen, um eine möglichst hohe Schlagkraft zu entfalten.

Scrum Master

Der Scrum Master stellt die Einhaltung der Prozesse im Sinne von Scrum sicher. Der Scrum Master ist ein "Servant Leader" für das Scrum Team. Durch seine langjährige Scrum Prozess-Erfahrung ist er in der Lage, dem Team organisatorisch zu helfen und Probleme aus dem Weg zu räumen. Gleichzeitig ist er Sprecher und Befürworter nach Außen. Seine Aufgabe ist es, sicher zu stellen, dass die Zusammenarbeit aller Beteiligten reibungslos funktioniert.

Der Scrum Guide spricht hier zwar von Transparenz, doch im Deutschen ist an dieser Stelle der Ausdruck "Klarheit" wohl passender. Je klarer die Backlog-Einträge allen Beteiligten sind, desto höher ist die Wahrscheinlichkeit, dass in der Software/dem Inkrement auch das Umgesetzt wird, was der Intention des Backlogs entspricht. Weiterhin ist die Klarheit dessen was innerhalb eines Sprints umgesetzt wurde eine Voraussetzung für die weitere Arbeit an Backlog-Einträgen und die darauf aufbauende weitere Entwicklung. Es geht also darum ein Scrum-Team übergreifendes, gemeinsames Verständnis zu schaffen. Dies gilt insbesondere für die Artefakte. Diese Klarheit der Beteiligten am Scrum-Prozess ist also das Fundament auf dem die gesamte Software am Ende steht. Die konkreten Anleitungen des Scrum Guides zu diesem Aspekt sind verhältnismäßig vage. Unsere Ausgestaltung des Scrum Prozesses bei Taktsoft dient in erster Linie der weiteren Steigerung der des gemeinsamen Verständnisses.

Definition of Done

Die einzige konkrete Vorgabe zum Thema "Transparenz der Artefakte" im Scrum Prozess besteht darin, Projekt-übergreifend eine "Definition von Erledigt" zu schaffen, sodass das gesamte Team das gleiche Verständnis davon hat, wann ein Task abgeschlossen, beziehungsweise ein Backlog Item umgesetzt ist.

Wir orientieren uns primär am Scrum Guide. Doch dieser lässt vieles, insbesondere die Umsetzung betreffend, bewusst offen. Im Folgenden werden einige Aspekte behandelt, in denen wir über diesen Guide hinaus Vorgaben machen und die Teil unseres Agilen Prozesses sind. Dabei handelt es sich allerdings um eine Momentaufnahme. Wir stellen unseren Prozess kontinuierlich auf den Prüfstand und arbeiten Erfahrungen aus unseren Projekten ein.

Produktvision

Die Produktvision ist das in Worte gefasste Ziel des Projektes. Die Vision des zu erstellenden Produktes sollte von jedem Mitglied des Scrum-Teams und allen sonstigen Projektbeteiligten verstanden und verinnerlicht werden. Diese Vision sollte klar und schlüssig auf den Punkt gebracht sein, bevor der Scrum Prozess startet. Sie dient dazu, die Motivation hinter dem Projekt klar zu definieren, sodass sich alle Beteiligten darauf berufen und beziehen können.

Epic

Das Epic stellt im Scrum Prozess eine inhaltliche Klammer um mehrere User Stories dar. Auf dem iterativen Weg zu einem vollständigen Backlog, basierend auf User Stories, stellt das Epic den ersten/nächsten Schritt dar. Es fasst Anforderungen auf einer sehr hohen Abstraktionsebene zusammen. Das ausformulierte Epic ist daher womöglich auch deutlich umfangreicher als eine einzelne und umsetzungsbereite User Story. Es bedient sich aber, wenn möglich, bereits der Syntax einer User Story. Ein Epic kann durchaus zusätzliche Dokumentation in Form von (UML-)Diagrammen, Wire-Frames, etc. enthalten.

User Story

Die User Story ist der Hauptbestandteil eines jeden Backlog Items. Sie soll die vorliegende Anforderung aus Benutzersicht schildern. Durch die Vorgabe "Als <Rolle> möchte ich <Ziel/Wunsch>, um <Nutzen>" wird das Team im Scrum Prozess in die Lage versetzt, die Motivation hinter dem Feature zu erfassen um die notwendige Interpretations- und Transferleistung zu vollbringen. Ziel ist es dabei, die Backlog Items so zu halten, dass sie prinzipiell von jedem Stakeholder formuliert und verstanden werden können. Details zur technischen Umsetzung sind hierbei explizit nicht gewünscht. Zusätzlich zum Feature-Wunsch (und eigentlichen Story) gehören zu einer User Story grundsätzlich Akzeptanzkriterien. Diese grenzen die Story von möglichen Interpretationen ab und definieren harte Kriterien zur Überprüfung der Umsetzung. Im Zusammenhang mit User Stories wird oft das Akronym INVEST bemüht, um sie auf ihre Qualität hin zu überprüfen. Demnach sind die Kriterien für eine gute

User Story:

Independent (unabhängig): Eine User Story soll möglichst unabhängig von allen anderen User Stories umsetzbar sein.

Negotiable (verhandelbar): Sie soll Gestaltungsspielraum lassen. Ziel ist es nicht, ein Feature bis ins Detail zu beschreiben, sondern den Entwicklern die Motivation hinter der Story nahe zu bringen, damit sie in der konkreten Situation die ideale Lösung entwickeln können.

Valuable (nützlich): Der Nutzen einer User Story sollte klar ersichtlich sein. Auch hier geht es um die Motivation hinter der Story. Ein Feature, das dem Entwickler nicht einleuchtet, läuft Gefahr fehlerhaft umgesetzt zu werden.

Estimatable (schätzbar): Der Umfang der Story muss so verständlich formuliert und so hart abgegrenzt sein, dass der Aufwand zur Umsetzung vom Team geschätzt werden kann.

Small (klein): User Stories sollten Anforderung in kleinen Päckchen beschreiben. Eine Umsetzung sollte idealer Weise für einen Entwickler nicht länger als einen Tag benötigen. Wird festgestellt, dass eine User Story zu umfangreich ist, so sollte sie aufgeteilt werden.

Testable (testbar): Jede User Story sollte testbar sein. Dazu dienen insbesondere die Akzeptanzkriterien.

Akzeptanzkriterien

Die Akzeptanzkriterien (kurz AKs) dienen vor allen Dingen dazu, die Kommunikation im Team, zwischen den Entwicklern und dem Product Owner, zu erleichtern und den Entwickler zu ermächtigen, eine User Story autonom umzusetzen. Sie beschreiben im Detail, welchen Bedingungen (zusätzlich zu der definition of done) erfüllt sein müssen, sodass das Sprint-Backlog-Item als fertig entwickelt gilt.

Ruby on Rails

Der Scrum Prozess gibt prinzipiell keinerlei Vorgaben, was Technologien angeht. Nichts desto trotz erleichtert es die Entwicklung ungemein, wenn die genutzte Sprache und vor allen Dingen das genutzte Framework die Anforderungen unterstützt, die ein agiles Vorgehen wie Scrum stellt. Insbesondere Testbarkeit und weitreichende Unterstützung bei der isolierten Umsetzung einzelner Backlog-Itames sind Aspekte, die durch technische Unterstützung stark vereinfacht werden können. Hier leistet das Framework Ruby on Rails große Hilfe und unterstützt den Entwickler bei seiner täglichen Arbeit im Scrum Prozess wie kein anderes Framework.

Definition of Ready

Analog zur Definition of Done ist die Definition of Ready ein gemeinsames Verständnis davon, wann ein Task, bzw. ein Backlog Item im Scrum Prozess "actionable" ist. D.h. es ist ausreichend formuliert damit es geschätzt, in das Sprint Backlog aufgenommen und umgesetzt werden kann.

Test-Driven Development

Diese Methode ist womöglich die tiefgreifenste Vorgabe im Zusammenhang mit unserer Softwareentwicklung. Gleichzeitig ist es aber auch sehr schwer zu entscheiden, wie viel und was genau zu testen ist. Denn es geht darum sinnvolle Tests zu schreiben, die möglichst wenig zusätzlichen Aufwand erzeugen. Wie diese aussehen, ist stark von dem konkreten Backlog Item abhängig. Neben der eigentlichen Überprüfung der Funktionalität dient ein Test auch dazu, die Anforderungen aus dem Backlog Item in Code zu formulieren. Der Programmierer veranschaulicht durch seine Tests, zusätzlich zur eigentlichen Umsetzung des Backlog Items, seine Interpretation der User Story und der zur Verfügung stehenden Akzeptanz-Kriterien im Scrum Prozess.