Summary:
Das Team war erneut schnell, schneller als geplant und schneller als selbst eingeschätzt, aber es häuften sich auch die Probleme ...
Das Ergebnis:
Geplant waren für Sprint 2 total 25 Story Points (SP's), bei einer verfügbaren Zeit von 144h Stunden. Von den geplanten User Stories wurden nur 18 SP's umgesetzt, 7 SP's waren Not Done. Trotzdem hat das Team während des Sprints zusätzliche User Stories angenommen und somit insgesamt 28 Story Points verdient.
Interpretation, Sprint Burndown:Das Team hat in der Retrospective das Burndown Chart analysiert und kam zu folgenden Erkenntnissen:
- Wir sind schnell, aber ...
- Viele offene Pendenzen, Hindernisse - daher kein Progress bei 4 Stories (Blocking)
- Aufgrund der Blockaden musste das Team andere User Stories vorziehen, da sonst keine Arbeit
- Vorgezogene User Stories waren oft nicht abgeklärt- viele offene Fragen, Unklarheiten
Was war gut?
- User Story of Taskboard, quasi manuell, nach wie vor gut
- Resourcen konnten arbeiten, wie geplant
Was können wir besser machen?
- Vorgezogenen User Stories oft unklar, Plannig Phase fehlte, viel Input vom PO während des Sprints notwendig
- Es gab eine Demo vom System mitten im Sprint, nicht zum Demo Day wie geplant
- Administrative Arbeiten inkl. Aufwände fallen an, gehören aber nicht zu einer Story und tauchen nicht in der Sprint-Planung auf, was machen wir damit?
- Code Freeze vor dem Deployment wurde nicht für alle Teammitglieder kommuniziert, daher gab es anschliessend viele Merge-Konflikte im Subversion
- Release-Umgebung zur Demo nicht up-and-running, ungeplanter Aufwand im Sprint
- Es gibt keine Release Notes, was haben wir bisher gemacht?
- kein ScrumMaster zum Hindernisse lösen
- Sprint Übersicht ist gut, aber Gesamtperspektive fehlt - wo stehen wir? Werden wir das schaffen?
- Anwesenheit beim Daily Scrum nur sporadisch
Zurück zum 69er - Sprint 2 Planning & Estimation Meeting
[Update]
Weiter zum Sprint 3 Planning & Estimation Meeting
Keine Kommentare:
Kommentar veröffentlichen