Die Umsetzung eines digitalen Produktes auf Basis des Scrum Frameworks beginnt, wie bei allen folgenden Sprints auch beim ersten Sprint, mit dem Sprint Planning. Damit das Umsetzungs- bzw. das Scrum Team von “Null” auf “Hundert” starten kann, gilt es aber einige Voraussetzungen zu schaffen.

‍

Sprint Zero vs Vorprojekt? 

‍

In der Scrum Literatur gibt es dazu divergierende Ansätze, wie damit umgegangen werden kann. Die eine Gruppe der Diskussionsteilnehmer vertritt die Meinung, es braucht dazu einen sogenannten Sprint “Null”, die anderen schlagen dazu ein “Vorprojekt” vor, weil jeder Sprint das Ziel verfolgt, voll funktionsfähige Softwareinkremente zu liefern (wie es im agilen Vorgehen üblich ist) und das unter Umständen schwer möglich ist, wenn ein Scrum Team auf der grünen Wiese beginnt und sich zum Beispiel mit dem Fehlen jeglicher Infrastruktur und Architektur konfrontiert sieht.

‍

Zur Diskussion, ob Sprint Null oder Vorprojekt wollen wir nicht beitragen, weil es nach unserer Ansicht den Blick auf die eigentliche Fragestellung, was es braucht, um mit dem ersten Sprint Planning effektiv und effizient starten zu können, vernebelt. 

‍

In jedem Fall ist es sinnvoll, den ersten Sprint oder das Vorprojekt damit zu verbringen, die erste Version der Entwicklungsinfrastruktur sowie die grobe Architektur zu erschaffen. Das Scrum Framework definiert allerdings keinen Sprint „Null“ oder „Iteration Zero“, wie XP das bezeichnet – in Scrum beginnt die Arbeit mit dem ersten Sprint. Achtung: Diese 7 Fehler, sollten Sie bei der Umsetzung von Scrum vermeiden.

‍

Was ist das Walking Skeleton und wozu dient es?

Eine nach den Regeln von Scrum konforme Zielerreichung könnte im ersten Sprint das sogenannte „Walking Skeleton“ („das laufende Skelett“) sein. Dabei handelt es sich um ein vertikales Inkrement mit kaum geschäftlicher Funktionalität, jedoch eine minimale Implementierung der Architekturvision. Diese zeigt die essentiellen Elemente des Technologie-Stacks in ihrer jeweils einfachsten Ausprägung.

‍

• Es dient dazu, die Machbarkeit der Architekturvision zu beweisen. 
• Es enthält kaum (geschäftliche) Funktionalität, nur so viel, wie für den Beweis der Machbarkeit notwendig ist.
• Es bietet die Chance, die Architektur oder den Stack Ende-zu-Ende zu durchlaufen und damit auch die Basis für End-to-End-Tests.

‍

In den folgenden Sprints kann das Walking Skeleton mit „Fleisch“ an den Rippen – also geschäftlicher Funktionalität – angereichert werden.

‍

Was muss vor dem 1. Sprint noch beachtet werden?

Neben den vorbereitenden Maßnahmen bezüglich Infrastruktur und Architektur sind aber auch weitere Überlegungen vor dem ersten Sprint in der Praxis relevant. Dazu folgende Fragestellungen (inkl. Infrastruktur und Architektur), die sich üblicherweise vor dem ersten Sprint Planning stellen:

‍

Scrum Team

• Sind die Rollen für Product Owner, Entwicklerteam bzw. Umsetzungsteam und Scrum Master besetzt?
• Sind die nominierten KollegInnen des Scrum Teams entsprechende ausgebildet (z. B.: Scrum zertifiziert) bzw. Scrum erfahren?
• Sind im Entwicklerteam die notwendigen Kompetenzen vorhanden, um das Produkt Ende-zu-Ende zu entwickeln (Full-Stack)?
• Ist sichergestellt, dass bei den nominierten KollegInnen des Scrum Teams die notwendigen zeitlichen Kapazitäten für die Umsetzung vorhanden sind?
• Haben die KollegInnen des Scrum- bzw. Entwicklerteams bereits zusammengearbeitet oder braucht es eine “Storming Phase”?

‍

Scrum Framework

• Ist die Produkt-Vision verfügbar, dokumentiert und geteilt (siehe dazu Product Vision Board)?
• Sind DoR (Defintion of Ready) und DoD (Defintion of Done) definiert?
• Ist ein initiales Product Backlog (zumindest für die ersten 2 bis  3 Sprints) verfügbar?
• Liegt eine User-Story Map vor? Ist Wissen über die Funktionalität von Story Points vorhanden? 
• Besteht grundlegendes Verständnis für die Velocity in Scrum? 

‍

Infrastruktur & Architektur

• Ist der für die Umsetzung relevante Technologie Stack definiert?
• Liegt eine grobe Architektur vor?
• Ist eine automatisierte Test- & Entwicklungsumgebung bzw. DevSecOps Umgebung verfügbar?
• Sind entsprechende Tools zum kontinuierlichen Code & Security Monitoring verfügbar und an die CI/CD Pipeline angebunden?
• Sind Tools zum Führen von Product Backlog, Impediments, etc. verfügbar?
• Sind Werkzeuge für Remote Sessions, Video-Konferenzen, Chats für die laufende Kommunikation vorhanden bzw. eingerichtet.
• Sind geeignete Tools für Retrospektiven verfügbar?
• Sind die technischen Zugänge für das Entwicklerteam eingerichtet?

‍

Standards & Rahmenbedingungen

• Sind entsprechende UI/UX Guidelines bzw. Vorgaben vorhanden?
• Sind erste Design-Vorschläge oder Mockups verfügbar?
• Sind Vorgaben im Kontext Informationssicherheit und Datenschutz definiert?
• Ist ein Testkonzept bzw. Code Reviews definiert?
• Sind einheitliche Qualitätsstandards bzw. Coding Standards definiert, um technische Schulden zu vermeiden?

‍

Unsere Empfehlung: Statt Zeit in die Diskussion zu investieren, ob ein sogenannter “Sprint Null” oder ein Vorprojekt die bessere Wahl ist, empfehlen wir den Blick darauf zu richten, was es im Vorfeld zum ersten Sprint Planning braucht, um mit der Umsetzung möglichst produktiv starten zu können.

‍

‍

Wissen Sie, was Ihre User wirklich wollen?

Mit User Story Mapping können Sie das in 4 einfachen Schritten herausfinden!