69er - Sprint 3 Planning & Estimation Meeting

Der 3. Sprint im 69er Projekt steht an und es gilt erneut: Team, let's plan!, ABER bei diesem Planning & Estimation Meeting gibt es eine Besonderheit, die ich in meinem agilen Dasein bisher auch noch nicht erlebt habe - der Product Owner ist nicht anwesend.

Wir haben vom PO mit auf dem Weg bekommen, dass auch im kommenden Sprint der Schwerpunkt auf dem User Interface liegen soll, denn nach nunmehr etlichen Iterationen beim Design haben wir eine finale Version, endlich.

Ok, wie sieht es mit den Ressourcen aus?


Plannning & Estimation

Da wir in diesem Sprint nicht so viel verfügbare Ressourcen haben, geht das Team mit weniger geplanter Arbeit in den Sprint. Nimmt man den Durchschnitt aus Sprint 1 und Sprint 2 beträgt die Velocity bisher 23 Story Points/Sprint. Um den limitierten Ressourcen Rechnung zu tragen, wollen wir 20 Story Points annehmen.

Das Team geht Story für Story aus dem Backlog durch und fragt zunächst, ob alle Fragen benantwortet sind, oder anders gesagt, wissen wir, was hier die Aufgabe ist. Wenn nicht, wird das an der Story vermerkt und diese zurückgelegt. Der interim ScrumMaster geht diesen Stories im Sprint nach und klärt die Fragen.

Gut, nachdem alle Stories im Backlog sortiert wurden nach klar und unklar, beginnt das Team die Arbeit zu schätzen. Dabei werden pro User Story kurz die Task herausgebrochen (nur grob) und überschlagen. Am Ende kommt man auf die Story Points pro User Story.

Und so sieht Sprint 3 aus:

Das Team hat 20 Story Points angenommen. Diese 20 SP's entsprechen ca. 81h Arbeitsaufwand. Verfügbare Arbeit ist 78h, d.h. wir haben ein kleines over commitment.

[Update]

Weiter zur Sprint 3 Retrospective

Zurück zur Sprint 2 Retrospective

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

69er - Sprint 1 Planning & Estimation Meeting

Heute hat das Team gemeinsam die Aufwandschätzung und Planung vom Sprint 1 für das 69er Projekt absolviert. Für alle ein ganz neue Aufgabe, die mit dem agilen Vorgehen nach Scrum eingeführt wurde. Trotz 4 arbeitsintensiven Stunden kann sich das Ergebnis sehen lassen:

Wie gehen mit vier User Stories und 12 Story Points in den ersten Sprint. Basierend auf dem aktuellen Wissenstand haben wir im schlechtesten Fall 98h Aufwand, den wir 132h unterbringen müssen.

Zurück zu Sprint Zero
[UPDATE]
Weiter zum Taskboard

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 ...

The the beat - the XP beat

Bei eXtreme Programming arbeitet das Team selbstorganisierend und –regulierend. Jede Arbeit die anfällt, um eine Aufgabe zu lösen, wird vom Team geleistet. Während der gesamten Entwicklung folgt das Team einem gelegeltem Arbeitstakt: Plan->Do->Reflect->Improve.

Jede Iteration beginnt mit einem Planning Meeting. Anwesend ist das Team und der Product Owner. Das Team entscheidet, welche User Storys aus dem Product Backlog in der nächsten Iteration realisierbar sind. Aus der angenommenen Arbeit entsteht das Iteration Backlog. Das Team nimmt nur soviel Arbeit an, wie es leisten kann.

Nach mehreren Planning Meetings bekommt man ein Gefühl dafür, wieviel das Team an Arbeit pro Iteration leisten kann. Damit kann man einen Rückschluss auf die zuvor gemachte Releaseplanung ziehen und gegebenenfalls frühzeitig reagieren.

Nach dem Planning Meeting beginnt das Team mit der Umsetzung. In dieser Zeit ist das Team auf sich gestellt. Äussere Einflüsse werden vom Product Owner vom Team ferngehalten. Das Team fokussiert sich auf die angenommene Arbeit. Ziel ist es, aus jeder User Story ein fertiges und brauchbares Feature zu entwickeln.

Im Anschluss an die Iteration werden alle User Storys vom Team vorgeführt. Hier ist das Team, der Product Owner und alle sonstigen Projektinteressierten anwesend. Der Product Owner kann die entwickelten Features selbst verwenden oder sie vom Team vorführen lassen.

Nachdem alle User Story vorgeführt wurden, zieht sich das Team zurück und tauscht positive und negative Erfahrungen aus. Ziel ist es, positive Punkte in der kommenden Iteration zu wiederholen, negative zu vermeiden.

Nach der Team Reflection beginnt der Zyklus Plan->Do->Reflect->Improve erneut.

Planning Poker

Play. Estimate. Plan.

Ein paar Trainer und Consultants von Mountain Goat Software hatten die Idee für eine einfache, webbasierte Web Applikation, mit der man Planning Poker spielen kann.

Planning Poker gehört Mountain Goat Software. Man kann die Software nicht kaufen oder runterladen, es ist Applikcation-as-service Lösung, online verfügbar. Man muss nur einen Account anlegen und los gehts ...

Um einen Planning Poker zu spielen, muss man einen Account haben, ein Spiel eröffnen und seine Teammitglieder einladen, indem man einen Link verschickt.

Um Planning Poker spielen zu können braucht man nur einen Browser. JavaScript muss aktiviert sein.

Bug vs. Feature

Nein, ein Bug ist kein Feature!

Während des Sprint 5 Planning Meetings hat sich erneut herausgestellt, dass das Verständnis über die Frage was ein Bug ist und was ein Feature, zwischen Team und Product Owner stark abweicht.

Für den Product Owner ist alles ein Bug, was betriebsstörend ist - alles was er als Input von Dritten bekommt, ist ein Bug. Aha! Das ist so nicht richtig, obwohl dies aus Kundensicht durchaus richtig erscheinen mag. Dazu kommt die Tatsache, dass der Product Owner in der Vergangenheit gelernt hat, dass ein Bug mit "fix asap" immer gleich vom Team realisiert wird, während Features immer im Sprint geplant werden und daher länger brauchen, bis sie wirksam werden.

Ein Bug aus Sicht des Team ist, wenn etwas nicht so funktioniert, wie es implementiert sein sollte und dadurch Fehler/Fehlverhalten auftreten, z.B. "Wenn man die AGB's anklickt bekommt man eine Fehlerseite".

Kein Bug ist etwas, was wie gewünscht realisiert wurde, aber für Endbenutzer so nicht brauchbar ist (das sollte eigentlich nie vorkommen!), z.B. "Im Email wird der Name und Vorname nicht angezeigt". Wie auch, wurde so nie implementiert! Das ist nach der Defintion vom Team ein Change Request und damit wird es als User Story im kommenden Sprint geplant und priorisiert.

Eine nicht unwichtige Überlegung, die man in diesem Zusammenhang anstellen muss, ist das Release Management. Wenn das Team auf der Release Branch ein Feature realisiert, der als Bug gekennzeichnet ist, hat das teure Konsequenzen. Auf dem Release entwickelte Dinge müssen in den Trunk gemerged werden. Dieser ist aber nach der Release Freigabe bereits fortgeschritten und die Code Basis hat sich unter Umständen bereits markant verändert. Der Merge vom Release Branch in den Trunk kann sehr teuer werden. Wenn dann noch eine Datenbankänderung dazu kommt, ist die Auslieferung des kommenden Releases vom Trunk aus sehr aufwendig.

Sprint 5 Planning Meeting

Sprint 1 bis 5 wurden bisher nicht mit dem Ansatz von User Stories durchgeführt. Bisher wurden vom Kunden nur Abkürzungen, Satzfragmente order Stichworte ins Product Backlog aufgenommen. Daraufhin gab es sehr ausführliche Planning Meetings und das Team hat on-the-fly während des Meetings im Wiki quasi die Spezifikation geschrieben, während der Product Owner seine Gedanken ausführt.

Das hat in der Vergangenheit dazu geführt, dass das Team zwar nach agiler Methodik iterativ arbeitet, aber agile Software Entwicklung war das nicht. Dies und der dringende Wunsch User Stories einzuführen haben dazu geführt, dass Target Process eingesetzt wird.

Im Sprint 5 Planning Meeting heute hat das Team während der Präsentation der Wünsche des Product Owners im Target Process die Aufgaben zu User Stories umgewandelt. Das war recht einfach, denn das Verhaltensmuster des Product Owner war immer das gleiche:
Jeder Backlog Eintrag, z.B. "Performanceoptimierung" wurde vom Product Owner immer selbst kommentiert, z.B. "Der Hintergund ist folgender: Wir bekommen von unseren Benutzern immer ...." Eigentlich liegt die User Story bereits auf der Hand: "Ein Benutzer bekommt nach der Suche innerhalb von 5ms eine Trefferliste angezeigt".

Während der Product Owner mit Powerpoint seine Wünsche präsentiert, wurden zusätzlich noch Notes und Contraints in der Story definiert, z.B. "Note: bei mehr als 1000 Treffer wird keine Trefferliste anzeigt, sondern ein Hinweis", "Contraint: es wurde mindestens ein Suchkriterum eingegeben".

Test Cases pro Story wurden in dieser Sprint Planung noch nicht erfasst. Das ist der gute Vorsatz für das kommende Planning Meeting, wenn alle Beteiligten mehr Erfahrung mit User Stories haben.

Best Practice: Konzeptionelles und Co.

Wie plant man konzeptionelle Arbeit in einem Sprint?

Hintergrund: Aus Sicht des Product Owners ist nicht alles, was er dem Team als Wunsch für den kommenden Sprint präsentiert, eine User Story. Es kommt oft vor, dass der Product Owner vom Team ein Konzept mit Lösungsalternativen für ein Problem haben möchte, um bei seinem Auftraggeber eine Entscheidungsbasis zu präsentieren. Oft spielen hier Kosten und Nutzen von diversen Alternativen eine grosse Rolle. Da der Product Owner nur das "Was" in das Team bringt und das Team über das "Wie" entscheidet, kann nur das Team eine Entscheidungsgrundlage erbringen. Das Team analysiert den Ist-Zustand und definiert das Delta zum Soll-Zustand. Dann werden verschiedene Alternativen ermittelt, wenn möglich.

Wie schreibt man so eine Story? Wie plant man das in einem Sprint ein?
Man könnte argumentieren, dass alles was keinem Benutzer etwas bringt keine User Story ist.
Aus Sicht des Product Masters stellt die Sprint Planung das Auftragsverhältnis für den kommenden Sprint dar. Es kann nur das abgerechnet werden, was Teil des Sprints ist. Wenn es also keine User Story ist, trotzdem im Sprint geplant werden muss, was ist es dann?

Ein Epic! Das Team geht bei Konzeptarbeit folgendermassen vor:
Es wird ein Epic(=Feature im Target Process) angelegt, z.B. "Der Administrator kann den Content X der Homepage selbst gestalten". Das Team ist der Meinung, dass man eine Applikation gebaut hat. Diese Funktionalität liesse sich besser durch ein CMS realisieren. Damit ist dem Product Owner nicht geholfen. Er sagt, er braucht dass, das Team meint, das sollten wir nicht tun. Wir könnten das allerdings schon.
Der Product Owner meint, er wisse das schon, aber er brauche für den internen Entscheidungsprozess bei sich eine Entscheidungsgrundlage. Also erfasst das Team eine User Story für Konzeptarbeit innerhalb des Epic, z.B. "Der Product Owner erhält ein Lösungskonzept mit Entscheidungsalternativen". Dazu kommt eine weitere User Story innerhalb des Epic: "Der Administrator kann den Content X der Homepage selbst gestalten." Beide User Stories werden vom Team geschätzt und im Rahmen der Sprint Planung geplant.

Im Lösungskonzept werden pro Alternative Story Points geschätzt. Wenn der Entscheid gefällt wurde, kann man im kommenden Sprint sofort mit der Implementierung beginnen.

Sprint 1 Planning Meeting

Das erste Planning Meeting nach Scrum

Der Product Owner trifft das Team. Er stellt seine Wünsche dar - Powerpoint Präsentation. Das Team ist konfrontiert mit Satzfragmenten, die teilweise mit Screen-Shots kombiniert sind.

Ratlosigkeit!
Das Team hatte im voraus vereinbart, das ein Teammitglied im WIKI die Planung dokumentiert. Somit wurde pro PPT Slide eine Wiki Page angelegt, denn das Team hatte zu den Satzfragmenten des Product Owners viel Fragen.

Die Fragen wurde auf Ebene "Business" erläutert, technische Details und konkrete Spezifikation wurden nicht besprochen. Das Team hat lediglich dokumentiert, was der Product Owner wirklich möchte.

Nach 4 h war die Planung vorbei und das Team war mehr oder weniger zufrieden mit dem Meeting. Man war es gewohnt, dass der Produkt Owner keine Spezifikation liefert, die ein Entwickler erwartet ... muss er auch nicht!

Nach Scrum sagt der Product Owner nur "Was". Das Team entscheidet über das "Wie".
Daran muss sich das Team erst gewöhnen.