Ein Sprint ist der zentrale Arbeitsrhythmus im Scrum-Framework: ein fester, wiederkehrender Zeitabschnitt von typischerweise 1 bis 4 Wochen, in dem ein Team ein klar definiertes Arbeitsergebnis liefert. Sprints sind das agile Pendant zum klassischen Projektmeilenstein, nur kuerzer, haeufiger und mit eingebautem Feedback-Mechanismus.
In Webdesign-Projekten strukturieren Sprints die Entwicklung von der ersten Wireframe-Skizze bis zum fertigen Launch und stellen sicher, dass der Kunde fruehzeitig und regelmaessig Ergebnisse sieht.
Anatomie eines Sprints
Sprint Planning
Zu Beginn jedes Sprints legt das Team fest:
- Sprint-Ziel: Was soll am Ende erreicht sein? (z. B. "Landingpage fuer Service X ist fertig und responsive")
- Sprint Backlog: Welche Aufgaben aus dem Product Backlog werden in diesen Sprint gezogen?
- Kapazitaet: Wie viel kann das Team realistisch schaffen? (basierend auf Velocity der letzten Sprints)
Taegliche Arbeit und Daily Scrum
Waehrend des Sprints arbeitet das Team fokussiert am Sprint-Ziel. Im taeglichen Daily Scrum (maximal 15 Minuten) teilt jedes Teammitglied:
- Was habe ich seit gestern geschafft?
- Was mache ich heute?
- Gibt es Hindernisse?
Sprint Review
Am Sprint-Ende praesentiert das Team das Ergebnis den Stakeholdern. Der Kunde sieht und testet das Inkrement und gibt Feedback, das in die Planung des naechsten Sprints einfliesst.
Sprint Retrospektive
Das Team reflektiert intern: Was lief gut? Was koennen wir verbessern? Welche konkreten Massnahmen setzen wir im naechsten Sprint um?
Sprint-Laenge waehlen
| Sprint-Dauer | Vorteile | Nachteile | Geeignet fuer |
|---|---|---|---|
| 1 Woche | Schnelles Feedback, geringe Planungsrisiken | Hoher Overhead durch haeufige Events | Kleine Teams, hohe Unsicherheit |
| 2 Wochen | Gute Balance aus Feedback und Umsetzungszeit | Standard, der fuer die meisten passt | Webdesign, Marketing, Entwicklung |
| 3 Wochen | Mehr Umsetzungszeit, weniger Event-Overhead | Unueblich, erschwert Synchronisation | Selten empfohlen |
| 4 Wochen | Grosse Arbeitspakete moeglich | Spaetes Feedback, hoehere Risiken | Komplexe Entwicklungsprojekte |
Sprint-Planung fuer Webdesign-Projekte
Typischer Projektablauf
Sprint 1 (Discovery): Persona-Workshops, User Flow-Definition, Moodboard-Erstellung, Wireframing der Hauptseiten
Sprint 2 (Design): UI-Design in Figma, Design System-Aufbau, Prototyping, erste Kundenpraesentation
Sprint 3 (Entwicklung): Frontend-Umsetzung, Responsive Design, CMS-Integration, interne QA
Sprint 4 (Launch): Content-Einpflege, SEO-Optimierung, Performance-Tests, Go-Live und Monitoring
Story Points und Velocity
Aufgaben werden nicht in Stunden, sondern in Story Points geschaetzt, einer relativen Groesseneinheit. Die Velocity (durchschnittliche Story Points pro Sprint) hilft bei der Prognose: Wenn das Team konstant 30 Story Points pro Sprint schafft, koennen Projektlaufzeiten realistisch kalkuliert werden.
Sprint-Ziele richtig formulieren
Ein gutes Sprint-Ziel ist:
- Ergebnisorientiert: "Kontaktformular ist funktionsfaehig und versendet E-Mails" statt "Am Kontaktformular arbeiten"
- Ueberprufbar: Am Sprint-Ende muss klar sein, ob das Ziel erreicht wurde
- Realistisch: Basierend auf der Velocity der letzten Sprints
- Wertstiftend: Jedes Sprint-Ergebnis soll einen messbaren Mehrwert liefern
Anti-Patterns: Was Sprints scheitern laesst
- Scope Creep: Neue Aufgaben werden waehrend des Sprints hinzugefuegt, ohne andere zu entfernen
- Kein Sprint-Ziel: Ohne uebergeordnetes Ziel wird der Sprint zu einer beliebigen Aufgabenliste
- Ueberladung: Mehr einplanen als das Team schaffen kann, fuehrt zu chronisch gescheiterten Sprints
- Sprint-Abbruch: Sollte nur in Ausnahmefaellen vorkommen, wenn das Sprint-Ziel obsolet wird
- Technical Debt aufschieben: Kurzfristige Abkuerzungen raechen sich in spaeteren Sprints
Sprints und Definition of Done
Jede Aufgabe, die im Sprint als "fertig" gilt, muss der vereinbarten Definition of Done entsprechen. Nur so wird sichergestellt, dass das Sprint-Inkrement tatsaechlich auslieferbar ist und keine versteckten offenen Punkte enthaelt.