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

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