Von der Idee bis zum lieferbaren Increment
Copyright Adam M. Skafi – ScrumExzellenz.de
Scrum ist mehr als nur Zeremonien und Rollen – es ist ein Denkrahmen für kollaborative, iterative Produktentwicklung. In der Praxis beginnt ein gut geführter Scrum-Zyklus nicht erst mit dem Sprint Planning, sondern mit der kontinuierlichen Pflege des Backlogs, abgestimmt auf realistische Kapazitäten, Stakeholder-Erwartungen und technische Machbarkeit.
Im Folgenden zeige ich den vollständigen End-to-End-Ablauf eines typischen Scrum-Zyklus, wie er in echten Projekten – inklusive Architekten, DevOps, UX und Cloud-Spezialist:innen – funktioniert.
1. Backlog Refinement
Bevor überhaupt ein Sprint geplant wird, bereiten der Product Owner und das Team gemeinsam das Product Backlog vor. In wöchentlichen Refinements werden:
- Anforderungen geklärt, technische Fragen besprochen
- Akzeptanzkriterien präzisiert (häufig mit UX-Beteiligung)
- Story Points geschätzt (z. B. per Planning Poker)
- technische Risiken und Abhängigkeiten identifiziert
Tipp: Integriere frühzeitig DevOps und Cloud-Kolleg:innen, um technische Randbedingungen zu prüfen (z. B. API-Anforderungen, Infrastrukturbedarf, Testbarkeit).
2. Sprint Backlog erstellen
Basierend auf dem priorisierten Product Backlog trifft das Team gemeinsam mit dem PO eine realistische Auswahl für den kommenden Sprint. Die Auswahl erfolgt basierend auf:
- Business-Priorität
- Abhängigkeiten
- technischer Machbarkeit
- verfügbarer Kapazität
Dabei hilft die historische Velocity als Referenzpunkt.
3. Sprint Planning durchführen
Jetzt startet das offizielle Scrum-Ritual:
Das Team bricht die Stories ggf. in Tasks auf, prüft technische Details (inkl. Architekturentscheidungen), definiert ein Sprint-Ziel und klärt, was realistisch geliefert werden kann.
Praxisnah: Cloud- & DevOps-Aufgaben sollten genauso eingeplant werden wie Feature-Entwicklung. Auch UI/UX-Aufgaben (z. B. Prototypen, Design-Reviews) sind Teil des Sprintumfangs.
4. Sprint starten & täglich synchronisieren
Der Sprint startet (z. B. in Jira). Täglich synchronisiert sich das Team im Daily Standup:
- Was wurde erledigt?
- Was steht heute an?
- Gibt es Blocker?
Effektiv wird das Daily, wenn das Team direkt am digitalen Scrum-Board arbeitet – mit transparentem Status zu Tickets, QA, Bugs und technischer Umsetzung.
5. Sprint Review – gemeinsam Ergebnisse zeigen
Am Sprintende präsentiert das Team das „Done“-Increment – also alles, was potenziell auslieferbar ist. Im Review mit Stakeholdern wird:
- demonstriert, was gebaut wurde (inkl. UI/UX-Demos, API-Funktionen etc.)
- Feedback eingeholt
- über neue Anforderungen oder Kursanpassungen gesprochen
Ein guter Review stärkt Vertrauen, bringt Klarheit und ermöglicht frühzeitige Steuerung.
6. Sprint Retrospektive – Team & Prozess verbessern
Nach dem Review reflektiert das Scrum-Team intern:
- Was lief gut?
- Was sollte gestoppt oder verändert werden?
- Welche Verbesserungen nehmen wir in den nächsten Sprint mit?
Praxisbewährt: Nutzt eine Confluence-Retrospektive mit Kategorien wie Keep Doing, Stop Doing, Start Doing, um Maßnahmen transparent zu erfassen.
7. Neuer Zyklus – Lernen, liefern, verbessern
Nach der Retrospektive beginnt der nächste Sprint – mit frischen Erkenntnissen, besserem Fokus und iterativer Verbesserung. Genau das macht den Scrum-Prozess in der Praxis erfolgreich: kontinuierliches Lernen, offene Kommunikation und teamgetragene Verantwortung.
Fazit: Scrum in der Praxis ist Teamarbeit mit Klarheit
Scrum entfaltet seine volle Wirkung nur dann, wenn alle Rollen – von PO über UX bis DevOps – aktiv mitgestalten. Die Iterationen sind keine Checkliste, sondern ein gemeinsamer Rhythmus für Qualität, Geschwindigkeit und nachhaltige Produktentwicklung.
Wer Scrum professionell lebt, schafft mehr als nur funktionierende Software – nämlich Vertrauen, Transparenz und echte Wertschöpfung.