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

Ein agiles Projekt geht weiter

Eine Web Applikation, die in einem agilen Projekt im vergangen Jahr konzipiert und fertiggestellt wurde, wird nun weiterentwickelt. Das Backlog ist gefüllt, alle User Stories sind geschätzt und der erste Sprint geplant. Ein neues Team steht vor der anspruchsvollen Aufgabe die Weiterentwicklung zu bewerkstelligen.

Bis zum letzten Release in 2007 (interne Bezeichnung: SOMMAR) wurden 80 Story Points in 5 Sprints abgearbeitet. Mit der Weiterentwicklung standen zum 29. Februar'08 20 Story Points verteilt auf 9 User Stories und 3 Bugs an. Das Team wurde auf 2 Entwickler reduziert, wobei ein Entwickler das Projekt nicht kannte. Aufgrund des kleineren Teams und dem notwenigen Wiederaufbau der gesamten Entwicklungsumgebung ist man zunächst im Sprint 7.1 von einer Velocity von 5 SP ausgegangen, ab Sprint 7.2 dann von 10 SP. Nach 2 Sprint sah das Ergebnis so aus:

Sprint 7.1: 5 SP geplant, 6 SP gleistet


Sprint 7.2: 10 SP geplant, 12 SP geleistet

Wir waren in der glücklichen Lage, dem Kunden zweimal hinterander zu informieren, dass wir vorzeitig fertig sind und er je noch eine User Story "gratis" haben kann.

Die Zufriedenheit und das Vertrauen des Kunden, auch ein Jahr nach erfolgreichem Abschluss des Projekts, konnte nachhaltig bestätigt werden. Das macht sich positiv bzw. negativ in den Zahlen bemerkbar - je nachdem wie man es betrachtet.

Wir, die Auftragnehmer, haben vom ursprünglich offerierten Aufwand nur 2/3 der Kosten verrechnen können, weil wir zu pessimistisch geschätzt haben. 1/3 vom Umsatz laut forecast wurde nicht erwirtschaftet! Kurzfristig betrachtet - nicht gut, aber mittel und langfristig ein dicker Nagel im Brett!

Der Kunde, sichtlich beeindruckt und zum wiederholten Mal mehr als zufrieden, beauftragte das Team selbst ein paar neue, coole und fancy Ideen zu entwickeln, die man als Feature in das Produkt einfliessen lassen könnte. Gesagt - getan!

Wie es weitergeht, werde ich in einem der nächsten Posts berichten.

Agile Estimation, Mike Cohn

Wie gross ist ein Scrum Team?

Gibt es eine absolute Obergrenze für die Teamgrösse? Lässt sich ein Scrum Team beliebig skalierien? Gibt es immer nur einen Product Owner? Wie muss man sich Scrum bei einem Team von 400 Entwickler vorstellen? Wie schätzt ein Scrum Team den Aufwand?

Mike Cohn von Mountain Goat Software beantwortet diese Fragen bei onSoftware, ein Podcast von InformIT.

Scrum Projekt Abschluss

Wir schreiben die 10. Woche im aktuellen Scrum-Projekt und nach der Auslieferung von Release 4.0. am 18.Juni geht das Projekt dem Ende zu.
Momentan gibt es noch ein paar Abnahmen mit dem Kunden und die Inbetriebnahme beim Provider. Dannach ist das Projekt abgeschlossen. Zeit, mal ein paar Zahlen zu generieren:

Zeitraum: 13. April bis 18. Juni, 47 Arbeitstage
Team: 4 Developer, 1 Product Owner, 1 Scrum Master

# Story Points: 80 PT
Gesamtaufwand: 188 MT (47 Tage x 4 Developer)

# Sprints: 5, davon 1x 3 Wochen, 2x 1 Woche, 2x 2 Wochen
User Stories/Sprint: 9PT/1, 1PT/2, 26PT/3, 23PT/4, 21PT/5
Durschnitt/Sprint: 16 PT pro Sprint

# Releases: insgesamt 4
User Stories/Release: 9PT/1, 27PT/2, 23PT/3, 21PT/4
Durchschnitt/Release: 20 PT pro Release

# Bugs: 24

Ok, der Blick zurück - jetzt wird's interessant. Wie wurde denn das gesamte Projekt vor Beginn vom Team geschätzt?

Insgesamt wurden 50 Story Points für die gesamte Realisierung VOR Projektbeginn geschätzt. Aus Erfahrung aus anderen Scrum Projekten ist man von 2.5 MT pro 1 SP ausgegangen. Das ist die Basis für die Schätzung. Mit einer pessimistischen und optimistischen Abweichung kann man den Know-How Gap vom neuen Projekt ein bischen ausbalancieren. Mit einer Abweichung von -25% und + 40% kommt man dan bei optimisticher, realistischer und pessimistischer Schätzung auf:

Mit heutigem Wissen kann man dass richtige Verhältniss MT pro User Story leicht errechnen:

Die Aufwandschätzung lag also im realistischen Bereich oberhalb der +40% Grenze!!! Mehr als doppelt so teuer! Die berichtigte Aufwandschätzung sieht wie folgt aus:



Bleibt die Frag offen, wieso 50 SP geschätzt und doch 80 realisert worden..... Das genau ist der Vorteil von agiler Entwicklung. Ein mal mehr war der Kunde "moving target" - d.h. er hat seine Prioritäten im Projekt verlangert, neue Ideen eingebracht und andere verworfen.

Was ist ein Story Point

Soll man eine Aussage über den Aufwand für eine Aufgabe machen, ist man gezwungen zu Schätzen. Je nachdem, wieviel Erfahrungen man hat, um die Aufgabe zu lösen, oder ob man eher optimistisch oder pessimistisch schätzt, oder, oder, oder kommt man zu einer anderen Aussage - eben einer Schätzung.

Wie auch immer man zu einer Schätzung kommt wurden meistens folgende Punkte mit einkalkuliert:

• Risiko
• Know-How
• Komplexität
• Zeit
• Qualität
• Resourcen

Story Points sind eine Einheit für Komplexität (ausschliesslich). Sie dienen der Schätzung von Aufwand für die Erledigung einer Aufgabe. Beispiel:

Wie komplex ist es, vom der Wohnungstür zum nächstgelegenen Supermarkt zu gelangen. Nehmen wir an, es ist 1. Wie komplex ist es dann wohl, von der Wohnungstür zum nächstgelegenen Flugplatz zu kommen? Vielleicht eine 3. Dass bedeutet, dann die Bewältigung der zweiten Aufgabe 3-mal so komplex ist, wie die für Aufgabe eins.

Man macht also bewusst keine Aussage über Zeit, Resourcen, Know-How oder ähnliches. Man versucht vergleichbare Aufgaben in Komplexitätsrelationen herunterzubrechen. Gebräuchlich ist die Fibonacci Folge 1,2,3,5,8 - nicht mehr!
Wenn man ein paar mal mit Story Points geschätzt hat, bekommt man sehr schnell ein Gefühl dafür, wass eine 1, 2 oder 5 ist. Da das Team die Story Points pro User Story definiert, hat der Kunde einen Feedback. Zusammen mit dem ihm bekannten Business Value kann er nun die Priorisierung festlegen. User Stories mit hohem Business Value und geringer Komplexität werden in aller Regel zu Beginn realisiert. Für alle anderen Kombinationen gibt es unterschiedliche Ansätze. So geht man bespielsweise davon aus, dass ein Feature mit einer hohen Komplexität, aber geringem Business Value auch möglichst früh in einem Projekt begonnen werden sollte, da eine hohe Komplexität das Team und den Kunde bezüglich gewonnenem Know-How am weitesten voranbringt. Man geht davon aus, dass nicht die Entwicklung des Produkts die grösste Errungenschaft ist, sondern das gewonnen Know-How ...

Best Practice: Estimation

Im Sprint 5 hat das Team erstmalig begonnen mit "echten" User Stories zu schätzen. Keine Spezifikation, nur ein Satz nach dem Muster X kann Y machen, um Z zu tun.

Der Product Owner hatte das Team beauftragt, neben dem eigentlichen Produkt eine kleines Neben(Nischen)produkt zu konzipieren. Man bewegt sich quasi auf der grünen Wiese. Diese Situation kann man mit einem Projektstart vergleichen. Man hat kein Systemarchitektur, kein ERM, kein Domain Model, kennt keine Schnittstellen, das GUI ist nicht definiert, etc.

Ok, wir haben aber etwas - ca. 35 User Stories!
Das Team ist konfrontiert mit dem "Wie" in Form von User Stories und soll nun schätzen - das funktioniert nicht, wie wir bitter erkennen mussten.

Lessons learned (in zeitlicher Reihenfolge):

1. Systemkontext muss kurz visualisiert werden, um das System und Umsystem zu erkennen
2. User Story Writing Workshop mit dem Team durchführen, um Rollen und Funktionen a la Brainstorming im Team zu erarbeiten. Das Team macht sich dadurch frühzeitig mit der Aufgabenstellung verraut und "lernt", was zu realisieren ist.
   
3. Ein paar einfache Wireframes/Story Boards sollten erstellt werden, damit man sich das vorstellen kann
4. Fragebogen für Experteninterviews erstellen und Experteninterviews durchführen
5. Interview mit potenziellen Benutzern durchführen um herauszufinden, was diese eigentlich möchten. Die Top 5 Hindernisse finden.
6. Ergebnisse des Fragebogens und der Interviews als Feedback ins Team bringen und dann die bstehenden User Stories neu formulieren bzw. hinzufügen
7. Estimation

Das funktioniert und die Akzeptanz im Team ist da!

Sprint 1 Estimation

Esitmation, jetzt wirds lustig.

Das Entwickler Team trifft sich zum ersten Mal um Aufwand in Story Points zu schätzen.
Möglich sind Bewertungen 1,2,3,5,8 und out of scope > 8.

Story Points wiederspiegeln die Komplexität bzw. Grösse, nicht Zeit.

Beispiel:
User Story: "Ich fahre von Stuttgart nach Zürich."
Story Points: 2
Zeit: mit dem Flugzeug < 1h, mit dem Auto ca. 5h, mit der Bahn etc.

Die einzige Aussage die man aus den Story Points ableiten kann, ist das es offensichtlich doppelt so komplex/aufwendig ist, wie bespielsweise: "Ich laufe von meiner Haustür zum Bahnhof", was wahrscheinlich SP=1 ist. "Ich fahre von Stutgart nach New York, USA" ist wohl eher SP=3 und "Ich fahre von Ottendorf, GER nach New York, USA" ist wahrscheinlich SP=5, da man erst in die nächste Grosstadt muss, um einen Aschluss an einen Internationalen Flugplatz zu bekommen. Wenn man mit demSchiff fahren möchte, eben zu nächsten Hafen.

Den Weg, den das Team einschlägt um das Ziel zu erreichen, entscheidet das Team. Eine Abnahme basiert auf dem releasefähigen Ergebnis, nicht auf Basis des gewählten Lösungsansatzes.

Nach ca. 4 h und einigen guten Zusprüchen des Scrum Masters hatte das Team die Estimation hinter sich gebracht. Die Stimmung im Team war eher drückend, denn niemand wusste so recht, wie man mit der Schätzung am Ende des Sprints rauskommt.

Klassischerweise braucht man einen Anhaltspunkt wie Anzahl der Views, Menge der Daten, Anzahl der Schnittstellen, betroffene Umsysteme etc. um eine Schätzung abzugeben. Diese Schätzung ist basiert dann auf Aufwand, nicht Komplexität....

Da dies der erste Sprint ist, kann man nicht aufgrund von Erfahrung sagen, wieviel SP's das Team durchschnittlich pro Sprint realiseren kann. Man hat also die verfügbaren Resourcen errechnet und eine Geschwindigkeit (Velocity) von 21 angenommen.