Scrum Sprint

Sprint Definition

Sprint hat viele Wortbedeutungen. Am ehesten aus dem Sport bekannt, wurde der Sprint als Kurzstreckenlauf mit größtmöglicher Geschwindigkeit auch in die Arbeitswelt übertragen. Hier ist der Sprint Teil des Scrum Prozesses für agiles Projektmanagement, welcher ursprünglich für die Softwareentwicklung konzipiert wurde, heute jedoch in vielen Bereichen Anwendung findet.

Für den Scrum Sprint ist die Metapher leicht irreführend, da es per Definition nicht darum gehen soll, eine Aufgabe möglichst schnell und unter größtem Energieaufwand zu erledigen, sondern vielmehr darum, effizient und nachhaltig zu arbeiten. Andererseits sind Scrum Sprints verglichen mit den Phasen im klassischen Projektmanagement (auch wenn es hier kein direkt übertragbares Äquivalent gibt) schon deutlich kürzer. Doch bevor näher auf die Zeiteinteilung eingegangen werden soll, folgt zunächst eine Einordnung des Begriffes Scrum und Scrum Sprint.

Scrum Sprint

Auch der Scrum Begriff hat seinen Ursprung im Sport: Der japanische Ökonom Ikujiro Nonaka verglich das Vorgehen mit dem dichten Gedränge (engl. Scrum) im Rugby. Diese Vorstellung griffen die beiden Softwareentwickler Ken Schwaber und Jeff Sutherland aus den USA auf und entwickelten die Scrum Methode als Rahmenwerk für das agile Projektmanagement. Ziel war eine effizientere Arbeitsweise, die es erlaubt, Anforderungen an individuelle Softwarelösungen, die Umsetzung von Projekten im Bereich Software, aber auch Projekte jeder Art, im Verlauf der Umsetzung nachzuschärfen und flexibel und agil auf Probleme reagieren zu können. Dazu haben sie neben den festen Rollen Product Owner, Scrum Master und Development Team Regeln aufgestellt, die in einem offiziellen Scrum Guide festgehalten und fortlaufend aktualisiert werden.

Der Sprint, auch wenn er manchmal als Synonym für Scrum oder losgelöst von diesem Vorgehensmodell verwendet wird, ist ein untergeordneter Teil der Scrum Methode.

Sprint Entwicklung

Der Scrum Sprint, welcher auch als Iterationsphase bezeichnet wird, meint per Definition eine zeitlich begrenzte Time Box innerhalb des Prozesses. Angesetzt sind hier je nach Vereinbarung, die im Sprint Planning getroffen wurde, zwei bis vier Wochen pro Sprint. Scrum sieht vor, dass während dieser Zeit durch das Entwicklungsteam ein Teilprodukt des fertigzustellenden Projekts entwickelt wird, welches als Inkrement des Sprints bezeichnet wird. Strukturiert wird die agile Arbeit des Entwicklungsteams durch einen sogenannten Sprint Backlog, welcher die Anforderungen in Form von priorisierten Aufgaben enthält. Der Sprint Backlog ist Teil des Product Backlogs, welcher die Gesamtheit aller Anforderungen an das Endprodukt enthält. In den Daily Scrum Meetings wird der Arbeitsfortschritt besprochen.

Für die Erstellung und Pflege von Sprint Backlog und Product Backlog sind Product Owner zuständig – eine der drei zentralen Rollen bei Scrum, auf die im Folgenden näher eingegangen werden soll.

Sprint Agiles Projektmanagement

Scrum Rollen

Das Vorgehen im agilen Projektmanagement bzw. der agilen Softwareentwicklung nach Scrum sieht drei festgelegte Rollen im Scrum Team vor: Product Owner, Scrum Master und das Entwicklungsteam.

Product Owner

Product Owner haben die inhaltliche Verantwortung für das Software Projekt und sind für die Herausarbeitung der Requirements und User Stories zuständig, formulieren diese in Aufgaben (= Backlog Items) um und erstellen dann einen Product Backlog und einen Sprint Backlog, welche als Orientierung für das gesamte Scrum Team dienen.

Scrum Master

Scrum Master haben die organisatorische Verantwortung für alle Prozesse. Ihre Aufgabe ist zudem die Moderation im Sprint Meeting und allen anderen Sprint Meetings. Sie sorgen für die Einhaltung der Scrum Regeln, Time Boxes und Deadlines.

Development Team

Aufgabe des Development Teams, oder zu Deutsch Entwicklungsteam, ist die Umsetzung von Sprint Backlog und letztendlich Product Backlog, aus welchen sie sich ihre Aufgaben selbst herausziehen und diese eigenverantwortlich und ohne Hierarchien innerhalb des Teams umsetzen.

Sprint Meeting

Unter Sprint Meeting lassen sich alle Treffen fassen, die innerhalb des Scrum Prozesses abgehalten werden, um den Sprint zu planen oder zu evaluieren. Anders als viele annehmen, gibt es für diesen Zweck über das Sprint Planning hinaus noch eine Reihe weiterer Sprint Meetings. Das Sprint Planning steht am Anfang, dann folgt die Sprint Review und am Ende steht die Sprint Retrospective. Im Gegensatz zum Daily Scrum finden Sprint Meetings nicht täglich, sondern in Abhängigkeit von der Dauer des Sprints statt.

Sprint Planning und Sprint Refinement

Das Sprint Planning ist wörtlich als Planung des anstehenden Sprints zu verstehen. Dabei werden die Anforderungen an das Inkrement, dem zum Ende des Sprints fertigzustellenden lauffähigen Zwischenprodukts, erfasst und eine “Definition of Done” festgelegt.

Sprint Refinement ist ein Begriff, der gerne verwendet wird, wenn eigentlich das Backlog Refinement gemeint ist. Hierbei ist kein extra Scrum Meeting gemeint, sondern eine agile Praxis, die zwar nicht im Scrum Guide vorgeschrieben ist, aber in vielen Teams angewendet wird und eine stetige Aktualisierung des Sprint Backlogs vorsieht. Ziel ist ein besseres Verständnis und Konkretisierung der Backlog Items. Diese Aktualisierung kann ganz unabhängig von Meetings stattfinden und auch nur von einem Bruchteil des Teams durchgeführt werden.

Sprint Review

Die Sprint Review steht in der Scrum Entwicklung am Ende des durchgeführten Sprints. Dabei kommt das Sprint Team mit Kunden und sonstigen Stakeholdern zusammen und präsentiert informell die Ergebnisse des Sprints. Es wird diskutiert, ob die gesetzten Ziele erreicht wurden. Die Stakeholder geben Feedback. Die Dauer der Sprint Review ist abhängig von der Länge des Sprints: Ist dieser vier Wochen lang, so sollte das Meeting auch nicht länger als vier Stunden einnehmen, was vom Scrum Master sichergestellt wird.

Sprint Retrospective

Die Sprint Retrospective bzw. Sprint Retrospektive findet im Anschluss an die Sprint Review statt. Während die Review mehr auf das “Was?” in der Entwicklung des Produktes abzielt, fokussiert sich die Retrospective auf das “Wie?”. An diesem Meeting sind keine Stakeholder beteiligt, sondern nur das Scrum Team, welches sich untereinander zurückmeldet, wie der letzte Sprint gelaufen ist – was gut funktioniert, wo noch Verbesserungspotenzial besteht und wie der Entwicklungsprozess optimiert und damit die Produktivität gesteigert werden kann. Die Dauer der Sprint Retrospektive sollte bei einem Sprint mit einer Länge von einem Monat ein Maximum von drei Stunden nicht überschreiten.

Kanban vs Sprint

Die Frage, ob sich Kanban oder Sprint am besten für das Projektmanagement eignet, müsste eigentlich Kanban vs. Scrum lauten, da dies die beiden populärsten Vorgehensmodelle im agilen Projektmanagement sind. Doch wie zuvor bereits erwähnt, wird der Sprint manchmal synonym mit Scrum verwendet. Wo liegen also die Unterschiede zwischen Kanban und Scrum?

Kanban - Projektmanagement im kleinen Team

Kanban ist die ältere der beiden Methoden und wurde erstmals von Toyota in der Automobilproduktion eingesetzt. Auf einem Kanban-Board mit den drei Spalten “Zu tun”, “In Arbeit” und “Fertig” wandern die Aufgaben auf Haftnotizen von Spalte zu Spalte, sodass ein Prozess von der Planung bis zur Fertigstellung übersichtlich abgebildet wird. Die Anzahl der Work in Progress, kurz WIPs genannt, ist dabei limitiert, sodass nicht zu viele Aufgaben gleichzeitig bearbeitet werden. In kurzen, aber regelmäßigen Meetings kann so anhand des Kanban Boards die Wochenplanung stattfinden. Auch viele Online Projektmanagement Software und Tools wie Trello oder Microsoft Planner verwenden die Kanban Methode in digitaler Form.

Da Kanban Boards ab einer bestimmten Größenordnung zu unübersichtlich werden, bieten sie sich eher im Management von einem kleineren Team an. Eine Möglichkeit ist jedoch auch, Kanban und Scrum zu kombinieren.

Scrum - Umfangreiches agiles Projektmanagement

Scrum ist im Gegensatz zu Kanban deutlich umfangreicher und ist als ganzes Rahmenwerk zu verstehen, während Kanban eine gute Methode zur Visualisierung ist, wozu Scrum keine exakten Vorgaben macht. Mit Scrum lassen sich weitaus komplexere Projekte umsetzen. Das Bearbeiten der Aufgaben innerhalb des Scrum Prozesses kann jedoch gewinnbringend mit Kanban visualisiert werden. So werden auch hier nicht selten Software und Online-Tools wie Microsoft DevOps als Projektplanungstool in der Softwareentwicklung eingesetzt, bei dem sich der Backlog nach dem Kanban Prinzip gestaltet: Hier kann die entsprechende Aufgabe, also ein Backlog Item, als “To Do”, “In Progress” und “Done” gekennzeichnet werden, welche User selbst kennzeichnen und zuweisen können.

Scrum bei TenMedia

Als moderne Digitalagentur in Berlin Mitte mit einem jungen Team setzen wir auch bei TenMedia auf ein agiles Projektmanagement nach Scrum. Bei der Umsetzung unserer Projekte steht nicht nur Effizienz in der Produktion durch Daily Scrum Meetings und Flexibilität beim Funktionsumfang, sondern vor allem die Zusammenarbeit mit Kunden auf Augenhöhe für uns im Vordergrund. Die Entwicklung von Individualsoftware erfordert auch ein individuelles und partnerschaftliches Vorgehen, was uns im Rahmen der Scrum Methode die Verwendung von Microsoft DevOps erlaubt, wodurch unsere Kunden den Entwicklungsprozess Sprint für Sprint hautnah mitverfolgen und Zwischenergebnisse und das aktuelle Produkt jederzeit mit Gastzugängen auf Testservern einsehen können.