Nach erfolgreichem Sprint 1 im 69er Projekt hat das Team nun ein Sprint 2 Planning Meeting durchgeführt.
Aufgrund der Erkenntnisse aus der Sprint 1 Retrospective soll der Fokus im kommenden Sprint auf dem User Interface liegen. Daher wurden solche User Stories vom Product Owner hoch gewichtet, die darauf einen Einfluss haben. Wichtig ist, dass am Ende des Sprints die bisherige Arbeit über den Product Owner hinaus noch anderen Stakeholders des Auftraggebers präsentiert werden soll.
Ok, was werden wir machen?
Wir haben eine andere Verteilung bei den Kompetenzen in diesem Sprint, eher User Interface lastig, und kommen daher insgesamt auf 144h verfügbare Zeit.
Vom Team angenommen wurden 25 Story Points.
Weiter zur Sprint 2 Retrospective
Zurück zur Sprint 1 Retrospective
Montag, 18. August 2008
Freitag, 15. August 2008
69er - Sprint 1 Retrospective
Am Dienstag war beim 69er Projekt Sprint 1 Demo Day und Retrospective. Team: Safe!
Summary:
Alles in allem kann man sagen, dass das Team unglaublich viele Arbeitspakete bewältigen konnte, mehr als erwartet.
Das Ergebnis:
Geplant waren 12 Story Points, 132h verfügbare Zeit
Realisiert wurden 19 Story Points in 143h. 31 geplante Stunden konnten nicht bezogen werden. Eine User Story wurde vom Product Owner nicht abgenommen, also 18 Story Points insgesamt.
Interpretation, Sprint Burndown:
In der Retrospective hat das Team das Burndown Chart und die Zahlen interpretiert und ein Fazit gezogen. Dabei kam heraus, dass man
Desweitern wurde durchleuchtet, warum das Team mit 31h Restguthaben in der verfügbaren Zeit mit 142h abrechnen konnte, obwohl nur 132h geplant waren. Ein Grund liegt auf der Hand: wir haben mit einem 6h-Tag geplant und kommen daher bei den verfügbaren Ressourcen auf 132h, worst case Szenario quasi. Ein anderer Grund war, dass die geplanten Ressourcen im Verlauf des Sprints nicht eingesetzt werden konnten. Eine Rahmenbedingung, deren man sich bewusst war, daher die 6h-Tag Planung.
Retrospective:
Zurück zum Sprint Burndown Chart und Taskboard
Demnächst: Sprint 2 Planning Meeting
Summary:
Alles in allem kann man sagen, dass das Team unglaublich viele Arbeitspakete bewältigen konnte, mehr als erwartet.
Das Ergebnis:
Geplant waren 12 Story Points, 132h verfügbare Zeit
Realisiert wurden 19 Story Points in 143h. 31 geplante Stunden konnten nicht bezogen werden. Eine User Story wurde vom Product Owner nicht abgenommen, also 18 Story Points insgesamt.
Interpretation, Sprint Burndown:
In der Retrospective hat das Team das Burndown Chart und die Zahlen interpretiert und ein Fazit gezogen. Dabei kam heraus, dass man
- zu pessimistisch geschätzt hat
- Arbeit geplant hatte, die man (noch) nicht machen konnte, daher zu "schnell" war
Desweitern wurde durchleuchtet, warum das Team mit 31h Restguthaben in der verfügbaren Zeit mit 142h abrechnen konnte, obwohl nur 132h geplant waren. Ein Grund liegt auf der Hand: wir haben mit einem 6h-Tag geplant und kommen daher bei den verfügbaren Ressourcen auf 132h, worst case Szenario quasi. Ein anderer Grund war, dass die geplanten Ressourcen im Verlauf des Sprints nicht eingesetzt werden konnten. Eine Rahmenbedingung, deren man sich bewusst war, daher die 6h-Tag Planung.
Retrospective:
Was war gut?
- Vorbereitende Arbeiten waren sehr gut , z.B. Infrastrukur war bereits da, als das Projekt im Sprint 1 begonnen hat
- Dokumentation im Wiki ist sehr gut, so findet man das verteilte Projekt Know-How
- ein Biergarten Besuch ;-)
- sehr guter Austausch im Team- man weiss praktisch immer, woran alle arbeiten
- Review ist sehr gut, verteilt das Wissen im Team, man lernt viel
- Daily Scrum wird als nüztlich empfunden, er ist kurz gehalten, fokussiert
- Product Owner ist zufrieden mit der Arbeit
Was können wir besser machen?
- Stunden aufschreiben! Am Sprint Ende war nicht ganz klar, wieviel Stunden wir aufgewendet haben
- Einschränkungen, Editierbarkeit im GUI bitte disuktieren, nicht einfach machen - z.b. nach Daily Scrum
- Was haben viele Tasks, die keine Story haben z.B. Testumgebung aufsetzten. Was machen wir damit?
Zurück zum Sprint Burndown Chart und Taskboard
Demnächst: Sprint 2 Planning Meeting
Donnerstag, 14. August 2008
69er - Sprint Burndown Chart
Ok, Sprint Burndown Chart! Das Team trifft sich jeden Tag zu einem Daily Scrum, max. 15min. Das gesamte Team ist anwesend, teilweise auch der Product Owner.
Nachdem jedes Teammitglied seinen heutigen Tag am Taskboard geplant hat, nimmt der Scrum Master die Zahlen in das Sprint Burndown Chart auf. Es wird während des Daily Scrum ausgedruckt und an das Taskboard geheftet - und natürlich beurteilt, jeden Tag!
Das Burndown Chart hier zeigt den 4. Tag im Sprint. In der oberen Tabelle werden die heutigen Ressourcen eingetragen, in der unteren die Restzeit.
Man kann erkennen, dass zwar 3 User Stories bereits auf Done sind, aber die verbleibende Zeit per heute knapp wird. Man sieht auch, dass eine Entwickler Ressource am 4. und 5. Tag mit 0 Stunden verfügbar ist, obwohl mit 6h geplant wurde. Ausserdem kann man sehen, dass bei diesem Tempo bald keine Arbeit mehr da ist, trotz Verknappung der Ressourcen. Der Product Owner wurde bereits am 3. Sprint-Tag informiert, ist nun anwesend und kann vorschlagen, was man als nächstes in den Sprint aufnehmen kann.
Zurück zum Taskboard
Demnächst:
Weiter zur Sprint 1 Retrospective
Nachdem jedes Teammitglied seinen heutigen Tag am Taskboard geplant hat, nimmt der Scrum Master die Zahlen in das Sprint Burndown Chart auf. Es wird während des Daily Scrum ausgedruckt und an das Taskboard geheftet - und natürlich beurteilt, jeden Tag!
Das Burndown Chart hier zeigt den 4. Tag im Sprint. In der oberen Tabelle werden die heutigen Ressourcen eingetragen, in der unteren die Restzeit.
Man kann erkennen, dass zwar 3 User Stories bereits auf Done sind, aber die verbleibende Zeit per heute knapp wird. Man sieht auch, dass eine Entwickler Ressource am 4. und 5. Tag mit 0 Stunden verfügbar ist, obwohl mit 6h geplant wurde. Ausserdem kann man sehen, dass bei diesem Tempo bald keine Arbeit mehr da ist, trotz Verknappung der Ressourcen. Der Product Owner wurde bereits am 3. Sprint-Tag informiert, ist nun anwesend und kann vorschlagen, was man als nächstes in den Sprint aufnehmen kann.
Zurück zum Taskboard
Demnächst:
Weiter zur Sprint 1 Retrospective
Abonnieren
Posts (Atom)