69er - Sprint 3 Retrospective

Gestern, 09. September war erneut eine Retrospective im 69er Projekt, nunmehr in der dritten Iteration.

Summary:
Auch in diesem Sprint war das Team schneller, aber leider auch schlechter. Der agile Arbeitsturnus hat sich so langsam eingespielt und das Team lebt Scrum. Trotzdem ist die Stimmung nicht gut. Der fehlende ScrumMaster ist für das Team spürbar. Viele Hindernisse die sich zu Blocking entwickeln, ohne Aussicht auf Behebung!

Das Ergebnis:
Geplant waren 20 Story Points bei einer verfügbaren Zeit von 78h, sportlich! Von den geplanten User Stories konnten 4 nicht fertig gestellt werden! Warum? 

Es gibt bei diesen Stories ein externes Partner-Unternehmen, auf dessen Service die Applikation angewiesen ist. Die Integration des Services ist zunächst trivial, trotzdem klemmt es. Das Partner-Unternehmen lässt uns hängen - das Team kommt nicht voran. Andere User Stories wurden einfach nicht gut genug getestet und vielen schlichtweg durch, als sie dem Product Owner präsentiert wurden. 

Und so sieht es aus:


Retrospective:

Was war nicht gut?

1. Die Rails Entwickler machen viele Tasks, die nicht Rails related sind - das ist langsam und macht kein Spass
2. Design ist noch immer nicht abgeschlossen, muss ständig neu angefasst werden - wird nie fertig
3. "Springende" Ressourcen sind nicht im agilen Prozess, sie leben ihn nicht
4. Viele externe Hindernisse, die das Team nicht lösen kann und sich "niemand" drum kümmert
5. Stimmung schlecht, Ergebnis stimmt nicht - wir erreichen unsere Ziele nicht

Uhhpf! Nicht gut ...

Was können wir besser machen?

1. Niemand arbeitet allein auf dem Projekt (auf täglicher Basis). Wir arbeiten nur, wenn mindestens 2 Teammitglieder arbeiten, bessere Resourcenplanung ausserhalb des Teams.
2. Reviews schneller(früher) machen, Arbeit (früher) abschliessen
   
3. Product Owner ist zwingend anwesend beim Planning und Demo Meeting

Nun steht der letzte Sprint vor der Tür. Das Product Backlog ist noch immer gut gefüllt und das Projektende ist absehbar. Werden wir es schaffen?

Zurück zum Sprint 3 Planning & Estimation Meeting

69er - Sprint 2 Retrospective

Am Dienstag vergangene Woche war erneut ein Sprint im 69er Projekt vorüber und es wurde präsentiert, was wir hatten.

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
  

Retrospective:

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

Nun, wenn wir die Stimmungbaromether ablesen sieht es nicht mehr so gut aus - wir müssen handeln!

Zurück zum 69er - Sprint 2 Planning & Estimation Meeting
[Update]
Weiter zum Sprint 3 Planning & Estimation Meeting

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

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

Story Points, Real Days und Tasks - Wie schätzt man Aufwand nach SCRUM

Eine interessante Frage, die ich kürzlich gestellt bekommen habe:

"Wird die Aufwandschätzung für eine User Story ganz normal in Stunden geschätzt und mit dem Faktor 1,33 Faktor für "real days" multipliziert oder ist der Faktor je nach Team unterschiedlich?"

In den agilen Teams, in den ich bisher gearbeitet habe, gingen wir von Story Points aus. Warum? Story Points (SP) beziffern die "Groesse" (Size). Sie haben keinen zeitlichen Aspekt. Wenn man User Stories mit SP's schätzt, kann man sie nebeneinander stellen und vergleichen:

Story A ist doppelt so "viel" wie Story "B". Story "C" ist 5 man so "viel" wie Story A.

Das ist sehr abstrakt und das ist gut so! Wichtig ist auf jeden Fall, dass die Story Points Scale endlich ist: z.B. 1-5, oder 10-100, etc. Sie sollte eine Progression ausdrücken, also nicht linear sein.

Reals Days ist eine andere Möglichkeit, User Stories zu schätzen.

Während des Sprint Planning Meeting 2, wenn das Team die Arbeit aufteilt, analsyisert und annimmt, werden die User Story in Tasks runtergebrochen und mit h versehen. Wenn man dann alle Stunden aller Team Members aufsummiert bekommt man eine geschätzten Aufwand für den kommenden Sprint. Legt man neben dran die Summe der verfügbaren Arbzeisstunden, kann man ungefähr erkennen, was dring liegt und was nicht.

• Beispiel: Sprint à 2 Wochen (10 Arbeitstage), Teamsize 3:
• Total verfügbare Arbeitszeit: 252 h (8.4h/Tag x 10 Tage x 3)
• Real Days: 180 h (6h/Tag x 10 x 3)
• Summe der Aufwandschätzung von n Task vom Team im Sprint Planning Meeting 2: 200h

In diesem Beispiel sind 20h zu viel im Sprint Backlog - es sollte etwas entfernt und ein Puffer eingeplant werden. Erfahrungsgemäss hat das Team beim Herunterbrechen der Task Dinge vergessen, die dann bei der täglichen Arbeit auffallen.

Jedes Teammitglied fügt solche Tasks während des Springs mit verbleibender Zeit (remaining time) in h ein. Der Scrum Master legt beim Daily Scrum jeweils das Sprint Burndown Chart auf und bespricht die Situation mit dem Team. Hier wird erkenntlich, ob die remaining time mit den noch verfügbaren Stunden übereinstimmt.

Das Sprint Burndown Chart ist vielleicht mal einen extra Post gut, mal sehen ...