Der Sprint

Die Begriffe Scrum und agil sind zurzeit in aller Munde. Doch wie ein Sprint in Scrum eigentlich abläuft und was das überhaupt ist und bedeutet, ist noch nicht allen bekannt. Wir machen Sie mit diesem Blogbeitrag Schritt für Schritt damit vertraut.

Was ist ein Sprint überhaupt?

Grundlegend handelt es sich um zeitlich begrenzte Zyklen. In dieser Zeit, die ursprünglich bei 30 Tagen liegt, werden bestimmte regelmäßige und wiederholbare Arbeitsabläufe immer wieder durchgeführt, wobei sich aber mittlerweile eine deutliche Tendenz in Richtung ein-, oder wie bei uns eingesetzt zweiwöchig zeigt. Das Ziel ist dabei, nach allen Sprints jeweils ein funktionsfähiges, einsatzbereites Softwareteil fertiggestellt zu haben. Dabei startet nach Abschluss einer Sprintphase sofort die nächste, wobei die einzelnen Sprints immer aufeinander aufbauen und unter anderem Entwicklungen aus vorherigen Sprints ersetzen oder als sogenannte “Lessons Learned” wieder aufgegeben werden.

Ein Sprint benötigt jedoch auch eine gewisse Vorbereitung sowie eine Reflektion, deswegen er besteht aus mehreren Teilen, die wir Ihnen im Folgenden genauer erklären. Bestandteile sind unter anderem der Backlog, das Sprint Planing, die eigentliche Softwareentwicklung, die Sprint Retrospektive, sowie das Sprint Review und die verschiedenen dazugehörigen Meetings.

Sprint Vorbereitung

Bevor wir einen Sprint überhaupt starten, müssen wir gemeinsam mit Ihnen erst einmal die Ziele und Tätigkeiten für diesen Timeframe festgelegen. Das wird bei Scrum mit dem Sprint Planing durchgeführt. Dabei entscheiden Sie während eines Telefongesprächs mit einem unserer Techniker, welche Aufgaben vom Product Backlog in den Sprint Backlog verschoben werden. Die Entscheidung, welche Anforderungen Sie verschieben möchten, liegt alleine bei Ihnen. Die Weise, wie Sie die Tätigkeiten erledigen, bestimmt das Scrumteam aber eigenständig.

Nachdem wir in diesem Meeting den Umfang geplant haben, hat der Product Owner, also Sie, keinen weiteren Einfluss darauf. Diese Beschränkung hat den Hintergrund, dass so während des Sprint Planings viel präzisere Entscheidungen getroffen werden, welche die Entwickler konzentriert und kontinuierlich erarbeiten können. Mit der Festlegung auf feste, zu erarbeitende Ziele, schafft sich das Entwickler Team zudem die Möglichkeit einer optimalen Zeitplanung. Dies erfordert jedoch auch strikteres Handeln bei kurzfristig zwischen zu schiebenden neuen Umsetzungen, damit die Entwickler nicht plötzlich mehr Arbeit zu tun haben, als sie tatsächlich umsetzen können. Auch dies ist ein weiterer, wichtiger Punkt, weshalb Scrum so erfolgreich ist. Aber keine Sorge: Support Arbeiten sind hierbei natürlich ausgeschlossen und werden von uns wie gewohnt bearbeitet.

Der Abbruch eines Sprints kann nur bei gravierenden Veränderungen im Projektumfeld von Product Owner oder Scrum Master durchgeführt werden. Das ist zum Beispiel der Fall, wenn sich die Anforderungen eines Kunden plötzlich entscheidend ändern. Ein solches Ende ist jedoch die Ausnahme.

Sprintphase

In der Sprintphase selbst findet die eigentliche Arbeit am Projekt statt. Hier werden die einzelnen Softwareteile entwickelt, sodass am Ende des gewählten Zeitraums ein funktionsfähiges Zwischenprodukt entsteht. Dabei findet nach Scrum täglich ine interne Abstimmung und Koordination der einzelnen Projekte statt. Das dient dazu, die Arbeiten zu überprüfen und Probleme, die das Erreichen des Ziels beeinflussen, zu besprechen. Ein Daily Scrum macht in der Praxis jedoch nur bei gewissen Projektgrößen tatsächlich Sinn. Wie wir in unserem Fall dabei genau vorgehen sehen Sie in nachfolgender Grafik. Außerdem ist der gesamte Ablauf in unserem Whitepaper SCRUM genauer erläutert. Dieses können Sie sich bei uns kostenlos downloaden.

Sprint Reflektion

Am Ende eines Sprints setzt der Scrum Guide normalerweise das Sprint Review Meeting an. Dort wird das Zwischenprodukt dem Product Owner präsentiert. Wir verzichten bewusst zum Teil auf dieses zusätzliche Meeting, da Sie bereits während der Entwicklung der einzelnen Softwareteile Informationen von uns bekommen und die Möglichkeit zum Test bekommen. Durch den stetigen Austausch und die Überprüfung Ihrerseits können wir die einzelnen Teile sofort anpassen und sie sind so zum Ende eines Sprints schon bereit zur Aufnahme in Ihr Live-System.

Die Sprint Retrospektive findet bei uns gegen Sprintende statt und beinhaltet ergänzend auch Teile des Sprint Reviews. Somit fassen wir Sprint Review und Retrospektive in einem Teil zusammen. In einem Telefonat mit einem unserer Techniker, der nicht aktiv an Ihrem Projekt beteiligt und somit viel objektiver ist, besprechen Sie den Ablauf des Sprints und filtern Verbesserungsmöglichkeiten gemeinsam heraus. Durch diesen ehrlichen Austausch wissen wir genau wo noch Potenzial in unserer Arbeitsweise liegt. So haben wir eine Rückmeldung, was gut lief oder verbesserungswürdig ist. Das wiederum ermöglicht es uns, gleichzeitig unsere Arbeitsweise stetig zu verbessern und außerdem auch Ihre Zufriedenheit konstant zu gewährleisten.

Nach dem Sprint ist vor dem Sprint

Nachdem die Vorbereitung, die Sprintphase, sowie die Reflektion samt Review Meeting abgeschlossen wurde, bedeutet das gleichzeitig den Start eines neuen Sprints. Das Schema läuft dann immer wieder gleich ab und beginnt solange von neuem, bis Ihre Softwarelösung fertiggestellt ist.

Wir hoffen, dass wir Ihnen mit diesem Beitrag die Abläufe eines Sprints etwas näher bringen konnten. Sie haben noch weitere Fragen zum Thema Sprint oder SCRUM? Kontaktieren Sie uns gerne oder hinterlassen SIe uns einen Kommentar.