Bei der digitalen Produktentwicklung sowie bei Projekten stellt sich regelmäßig die Frage nach dem Aufwand und der zeitlichen Dimension der Umsetzung. Insbesondere bei komplexen Vorhaben mit entsprechender Unsicherheit stellt dies eine Herausforderung dar. Oftmals ist zwar das Ziel klar umrissen, der Weg zum Ziel, sprich das “Wie”, und die konkreten Ausprägungen sind insbesondere zu Beginn eines Vorhabens unklar.
Erst im Laufe der Entwicklung und durch den sich daraus ergebenden Erkenntnisgewinn lassen sich die Anforderungen präzisieren. Genau für derartige Situationen kommen agile Methoden wie Scrum zum Einsatz und entfalten ihren vollen Nutzen und bieten viele Vorteile im Vergleich zum Wasserfallmodell.
Bei der Planung von Releases im Zusammenhang mit agilen Projekten stellen sich somit typischerweise folgende zwei Fragen:
- Wann wird eine festgelegte Menge an Anforderungen geliefert?
- Wie viel an Funktionalität kann bis zu einem bestimmten Zeitpunkt umgesetzt werden?
Relative Größenschätzung
In den klassischen Projektmethoden haben sich hierfür Zeitschätzungen in Einheiten, wie zum Beispiel in Personentagen oder Personenstunden etabliert. Anforderungen werden soweit detailliert, dass deren Umsetzung zeitlich abschätzbar ist.
Agile Methoden benutzen eine andere Technik. Hier wird nicht die Dauer einer Aufgabe oder einer User Story geschätzt, sondern nur deren Größe relativ zu anderen User Stories. In User Stories formulieren Product Owner die Anforderung der Anwender für die Lösung.
Story Points als Methode zum Schätzen
Die Dauer wird erst in einem zweiten Schritt über die Geschwindigkeit des Teams ermittelt. Da es im Bereich von Software keine genormte Einheit gibt, die die Größe einer User Story bestimmbar macht, werden Story Points als abstrakte Größe verwendet. Sie beschreiben die Größe der Features im Sinne von Umfang und Komplexität, und zwar relativ zueinander im Analogieverfahren. Für die Bemessung einer User Story nach Story Points kommen entsprechende Skalen zum Einsatz, die der zunehmenden Größe und somit implizit der zunehmenden Unsicherheit Rechnung tragen. Damit reflektiert sie die zunehmend größer werdende Unsicherheit der Schätzung, je größer die relativen Schätzungen zueinander werden.
Hier ein Beispiel zum einfacheren Verständnis:
Wenn Sie gefragt werden, wie groß Ihr Bildschirm auf Ihrem Schreibtisch im Verhältnis zu Ihrem Schreibtisch ist, werden Sie vermutlich relativ zügig und sicher sagen können, dass das Verhältnis beispielsweise 1:3 beträgt.
Werden Sie hingegen gefragt, wie groß Ihr Bildschirm in Relation zur Größe Ihres Bürogebäudes ist, dann wird Ihnen die Antwort vermutlich deutlich schwerer fallen, mit höherer Unsicherheit verbunden sein und die Relation ein Vielfaches von 1:3 sein.
Story Points Skala - Nichtlinear Skalen
Um das Schätzen von Features ähnlicher Größenunterschiede zu ermöglichen, bieten sich nichtlinearen Zahlenreihen via Zweierpotenzen an, womit dann jedes Element immer die doppelte Größe wie das vorangegangene hat (1, 2, 4, 8, 16, 32, 64, 128, ...). Diese Skala steigt jedoch rasch an und ist somit nur für Anforderungen mit sehr hoher Unsicherheit zielführend.
Bei weitem häufiger kommt die Fibonacci-Reihe (1, 2, 3, 5, 8, 13, 21, ...) als Skala für diskrete Zahlenwerte zum Einsatz, um Features zu schätzen bzw. einzuordnen. Hier ergibt sich jedes Element aus der Summe der beiden Vorgänger Elemente. Außerdem ist in der Praxis zu beobachten, dass Teams eine modifizierte Fibonacci-Reihe verwenden, die ab der Zahl 21 abweicht (1, 2, 3, 5, 8, 13, 20, 40, 100) und in der Regel für die Schätzungen von Größenordnungen völlig ausreichend ist.
Alternativ können noch abstraktere Schätzgrößen bzw. Einheiten verwendet werden, die völlig auf Zahlenwerte verzichten. Ein beliebtes Beispiel sind T-Shirt-Größen (S, M, L, XL, XXL). Diese Methode hat sich insbesondere beim Schätzen ganzer Epics als taugliches Verfahren bewährt.
Hinweis: Wenn lediglich Epics vorliegen, hat es sich als zweckmäßig erwiesen, zumindest ein Epic mit Size M und mit dem sich das Entwicklerteam komfortabel fühlt, in User Stories herunterzubrechen und auf dieser Ebene zu schätzen. Alle anderen Epics können dann im Analogieverfahren zum auf Ebene User Story geschätzten Epic via T-Shirt Sizing bewertet werden. Dies führt dann in der Praxis zu durchaus brauchbaren Ergebnissen.
Bei der konkreten Durchführung der Schätzung stehen diverse Verfahren zur Auswahl. Am häufigsten kommt in der Praxis Planning Poker zum Einsatz.
Entwicklungsgeschwindigkeit
Wenn nach dem Planning Poker die Story Points der Aufgaben bzw. User Stories feststehen, lässt sich noch nicht ohne weiteres die Dauer ableiten. Dazu bedarf es einer weiteren Größe, die Auskunft über die Geschwindigkeit gibt.
Bei agilen Methoden wird die Geschwindigkeit eines Umsetzungsteams anhand der Velocity, also der Größe bzw. des Umfangs der gelieferten Funktionalität pro Iteration gemessen. Diese Kennzahl gibt somit Auskunft darüber, wie viel Software gemessen in Story Points in einer Iteration bzw. einem Sprint voraussichtlich geliefert werden kann (Plan Velocity) oder geliefert wurde (Ist Velocity) und kann somit als Basis für die weitere Projekt bzw. Produktplanung herangezogen werden.
Um die Dauer zu ermitteln, reicht es, die mittlere Geschwindigkeit mit Punkten zu messen, also wie viele Features (gemessen in der Summe der Story Points) ein Team pro Sprint umsetzen kann. Über diese Zahl wird dann die Dauer für eine bestimmte Menge an Features berechnet, deren Größe ebenfalls in diesen Punkten geschätzt wurde.
Punkt- versus Korridorschätzung
Grundsätzlich bedeutet jegliche Planung die geistige Vorwegnahme zukünftigen Geschehens. Dies gilt in gleicher Weise für die Schätzung von Projektaufwänden. Einen zukünftigen Projektaufwand in einem einzelnen Wert auszudrücken, nennt man Punktschätzung.
Dies gelingt dann relativ gut, wenn das Projekt zeitlich überschaubar, gut beschreibbar (“Was” und “Wie), wenig innovativ, wenig komplex und von geringem Risiko ist. Außerdem sollte es keine oder nur geringe Abhängigkeiten von externen bzw. nicht beeinflussbaren Faktoren geben.
In Projekt-Szenarien, in denen das nicht der Fall ist, wie zum Beispiel bei hoher Volatilität der Anforderungen oder im Projektumfeld, wo somit agile Projektmethoden zum Einsatz kommen, führt eine exakte Punktschätzung des zu erwartenden Projektaufwandes (z.B.: 400 Story Points) zu einer Scheingenauigkeit. Diese wird dem Planungsgegenstand nicht gerecht.
Hinweis: dies bedeutet aber auch, dass während eines Projektes im Zuge des Sprint Planning Meetings eine exakte Schätzung der für den Sprint geplanten User Stories und somit Story Points erfolgen kann bzw. soll.
Als sehr viel praktikablerer Ansatz beim Schätzen von ganzen Projektvorhaben oder Releases hat sich in der Praxis daher die Planung bzw. die Schätzung von Bandbreiten herausgestellt, die so genannte Korridorschätzung. Das können dann sowohl “Von / Bis” Werte, als auch Best Case und Worst Case Szenarien sein. Daraus lassen sich einfach Mittelwert bzw. das Most Likely Szenario ableiten.
Die Korridorplanung kann zum einen durch die Schätzung der Story Points im Zuge des Planning Pokers erfolgen, also das Schätzen von “Von / Bis” Werten oder durch den Ansatz unterschiedlicher Velocity Varianten.
Am Ende ergeben sich daher Bandbreiten hinsichtlich Aufwand und in weiterer Folge hinsichtlich Investitionsbedarfs in einem Projekt, was der Realität sehr viel näher kommt, als die Festschreibung auf einen einzigen Wert.
Dieses Vorgehen schafft darüber hinaus die Basis für einen fortgeschrittenen Controlling-Ansatz, der mittels Einsatz von Methoden der systematischen Risikoanalyse und Risikosimulation zu einer echten Bandbreitenplanung führt und insbesondere bei kapitalintensiven Investitionsvorhaben als Entscheidungsgrundlage dienen soll.
Wie formuliert man User Stories?
8 Punkte, die Sie bei der Erstellung beachten sollten!
