Montag, 18. August 2008

69er - Sprint 2 Planning & Estimation Meeting

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

Freitag, 15. August 2008

69er - Sprint 1 Retrospective

Am Dienstag war beim 69er Projekt Sprint 1 Demo Day und Retrospective. Team: Safe!

Dashboard?
Originally uploaded by Jürg

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
Hintergrund: Look&Feel der Anwendung sind noch nicht final definiert. Interaction-Designer und Usability Experten arbeiten noch daran, trotzdem hat das Team im Sprint 1 bereits Funktionalitäten entwickeln könnnen, allerdings ohne visuellen Aspekt. Strenggenommen sind diese User Stories nicht DONE. Daher hat das Team eine virtuelle Persona konzipiert (Design-Checker) und eine User Story angehängt, die zur GUI Implementierung in einem späteren Sprint genutzt werden soll. Geplante und verschobene Aufwände/Tasks aus Sprint 1 wurden dort angehängt. Dieser Umstand erklärt den schnell Fortschritt.

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?
Die Stimmungsbarometer untermauern den aktuellen Befund - alles im grünen Bereich!

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