Ein Trick, um die Probleme des absoluten Schätzens auszugleichen, ist das Schätzen mit Hilfe von Story Points.

Diese Schätzung drückt im Gegensatz zum absoluten Schätze in Personentagen aus, wie hoch der Aufwand zweier Anforderungen im Bezug zueinander sind und kann darum auch als relative Schätzung bezeichnet werden. Ist eine Anforderung doppelt so anspruchsvoll wie eine andere, so hat sie auch doppelt so viele Story Points.

Statt Story Points werden für das relative Schätzen auch genre T-Shirt-Größen (S, M, XL, XXL) oder ähnliches verwendet. Diese Verfahren haben häufig den Vorteil, dass sie noch verständlicher als Story Points sind und sich damit zum Beispiel sehr gut zur Kommunikation mit Stakeholdern eignen, jedoch haben Story Points erfahrungsgemäß eine deutlich höhere Genauigkeit.

Story Points sind als eine virtuelle Einheit zu verstehen. Diese Einheit gibt an, wieviel Energie erbracht werden muss, um eine Anforderung umzusetzen.

Der aufmerksame Leser wurde jetzt sicher aufgeschreckt und fragt sich: „Wieso wird hier plötzlich die Anforderung geschätzt? Beim absoluten Schätzen konnten doch nur Tasks und keine Anforderungen geschätzt werden“.

Dies liegt daran, dass man beim absoluten Schätzen die Zeit schätzen will, die man benötigt um die Anforderung umzusetzen. Beim Schätzen mit Storypoints schätzt man jedoch die Energie, die die Umsetzung der Anforderung kostet.

In der Physik wird Energie als Leistung x Zeit definiert. Bei Story Points, als Maßeinheit für die Energie, die erbracht werden muss um eine Anforderung umzusetzen, verhält es sich ganz ähnlich:

Ein Story Point steht als Einheit für die Energie, die erbracht werden muss, um eine Anforderung umzusetzen. Da Energie Leistung x Zeit ist und man Leistung in unserem Zusammenhang als „Gehirnschmalz“ und Zeit als „Personentage“ betrachten kann, ist die Komplexität („Gehirnschmalz“ bzw. „Leistung“) bei Storypoints im Gegensatz zum Schätzen mit Personentagen variabel.

Leistung/Komplexität/Gehirnschmalz schließt dabei impliziet die Frage mit ein, wie viele Informationen aus der Anforderung hervorgehen. Ist die Anforderung bereits so formuliert, dass man sie nur noch herunter programmieren muss, enthält der Story Point eine hohe Zeit-Komponente, ist die Anforderung sehr unklar und muss darum noch einiges an Leistung investiert werden, um die Anforderung umfassend zu verstehen, so treibt die Leistungs-Komponente die Story Points nach oben.

Ich habe schon viele Teams erlebt, die sich sehr schwer getan haben unklare Anforderungen zu schätzen und darum auch beim Schätzen mit Story Points jede Anforderung komplett auseinander genommen haben, dabei wurde jedoch immer wieder deutlich: Es lohnt sich nicht. Wenn die Anforderung entwickelt wird, hat sie sich entweder schon wieder in Teilen geändert oder man hat die Analyse, die man während dem Schätz-Prozess gemacht hat, bereits vergessen, oder, oder, oder….

Das Schätzen mit Story Points wurde erfunden, eben damit man einfach und schnell Anforderungen schätzen kann, die man noch nicht im Detail kennt, ohne sie bis auf Task-Ebene herunter brechen zu können. Also seit mutig: Schätzt nicht nur die Zeit, sondern versucht in eure Schätzungen auch die Komplexität bzw. das Fehlen von Information einfließen zu lassen.

Velocity

Die Projektmanager unter euch werden sich jetzt natürlich fragen, was das mit den Story Points denn nun bringen soll. O.k., man kann so die Energie schätzen, die das Team auf eine Anforderung verwenden muss, aber diese Aussage alleine hat ja noch keinen Mehrwert.

Interessant werden Story Points erst, wenn man die Leistungsfähigkeit (Velocity) des Teams kennt, welches die Anforderungen abarbeitet. Hierzu misst man die Story Points, die ein Team in einer bestimmten Zeitspanne arbeitet.

Im Scrum, mit seinen zeitlich festen Iterationen, wird die Velocity über die Dauer eines Sprints gerechnet. Dauert ein Sprint zwei Wochen, so ist die Velocity die Anzahl an Punkten, die das Team in diesen beiden Wochen abarbeitet.

Ich mag persönlich mitlerweile zeitlich flexible Iterationen lieber. Dabei versucht man ein bestimmtes, meist fachlich definiertes Ziel zu erreichen und die Dauer der Iterationen so zu wählen, dass dieses Ziel erreicht werden kann. In solch einer Konstellation macht es Sinn die Velocity als Anzahl der Story Points zu definieren, die während der Iteration durchschnittlich am Tag gelöst wurden.

Erst wenn man die Velocity des Teams kennt, ist es möglich auf Basis einer Story Point-Schätzung eine Release-Planung zu machen oder auf Probleme im Team aufmerksam zu werden.

Fazit

• Das Schätzen in Story Points fällt einfacher als das Schätzen in Personentagen, da Verhältnisse und keine absoluten Werte geschätzt werden.
• Anforderungen müssen zum Schätzen nicht in Tasks heruntergebrochen werden, da in die Einheit Story Point nicht nur die benötige Zeit, sondern auch die zu erbringende Leistung (Komplexität) einfließt.
• Kennt man die Leistungsfähigkeit (Velocity) des Teams, so kann man Story Points in Personentage umrechnen.