Dieser Artikel geht folgenden Fragen nach:
- Was ist sind Bestandteile eines Sprints (Entwicklung, Testing, Refinement, Demo, etc.)?
- Was sind die Abhängigkeiten zwischen diesen Bestandteilen?
- Wie plant man sie zeitlich innerhalb eines Sprints ein?
Arbeiten in einem Sprint
| Task | Beschrieb | Betroffene Rollen |
|---|---|---|
| Systemdoku nachführen | Die Systemdoku wird nachgeführt, damit wir für jeden Release einen sauberen Dokumentationsstand haben | Business Analyst |
| Deployment | Das Deployment des Releases aus dem vorherigen Sprint wird auf Produktion deployed | Entwickler |
| Hotfix | Dringliche Probleme aus der Produktion müssen zeitnah mittels eines Hotfixes korrigiert werden | Product Owner, Business Analyst, Entwickler |
| Software entwickeln | Die Stories des aktuellen Sprints werden entwickelt | Entwickler |
| Software testen | Die entwickelten Stories werden getestet. Fehler müssen noch im selben Sprint nachkorrigiert werden (Fix) | Business Analyst |
| Anforderungen erarbeiten | Anforderungen für zukünftige Sprints werden erarbeitet | Business Analyst, Vertreter Business |
| Refinement | Business Analyst und Entwickler stellen sicher, dass beide Seiten die Anforderungen gleich verstanden haben | |
| Aufwände schätzen | Die Aufwände für die Umsetzung der Anforderungen für den nächsten Sprint werden geschätzt | Entwickler |
| Sprint planen | Die Aufgaben für den nächsten Sprint werden geplant | Product Owner, Business Analyst, Entwickler |
| Demo & Abnahme | Die im Sprint entwickelte Software wird präsentiert und abgenommen | Alle |
| Retro | Zusammenarbeit im letzten Sprint wird kritisch analysiert und Verbesserungsmassnahmen für die Zukunft werden definiert | Alle (optional: Vertreter Business) |
Zusammenhänge zu anderen Sprints
Der grösste Teil der Arbeiten zahlen auf dem aktuellen Sprint ein. Der Rest hängt mit dem nächsten Sprint zusammen:
Arbeiten für aktuellen Sprint
Diese Arbeiten sind der Kern des aktuellen Sprints:
- Software basierend auf den eingeplanten Stories entwickeln
- Software innerhalb des Sprints testen
- Fehler müssen noch im selben Sprint behoben werden
- Hotfix (optional)
- Kann jederzeit eintreten und hat zur Folge, dass eingeplante Tasks des Sprints unterbrochen werden müssen
- Demo des Sprint-Inkrements durch das Entwicklungsteam und danach Abnahme durch die Stakeholder
- Mittels Retro(spektive) Optimierungen für den nächsten Sprint identifizieren und einplanen
- Systemdoku basierend auf letztem Sprint-Inkrement nachführen
- Deployment der letzten Version der Software auf Produktion
Vorarbeiten für nächsten Sprint
Diese Arbeiten zahlen auf den nächsten Sprint ein. Eine gute Vorarbeit in diesen Tasks legt die Basis für den Erfolg des nächsten Sprints:
- Anforderungen für den nächsten Sprint erarbeiten
- Mittels Refinement die Anforderungen mit den Entwicklern abstimmen
- Stories für nächsten Sprint nach Aufwand einschätzen
- Tasks für nächsten Sprint planen
Beispiel: Organisation eines Sprints
Folgendes Beispiel illustriert, wie ein Sprint mit 2 Wochen Dauer strukturiert werden könnte:
Dabei wurden folgende Aspekte berücksichtigt:
- Betroffene Rollen pro Task
- Abhängigkeiten zwischen Tasks
- Aufwand pro Task