Story Points sind eine Einheit um die Größe von User Stories zu schätzen. Das bedeutet, Story Points nehmen eine wichtige Rolle bei der agilen Schätzung des Entwicklungsaufwands ein. Wenn Sie mit uns zusammenarbeiten, werden wir Schätzungen nur in Story Points angeben. Was diese aussagen und welche Vorteile sich für Sie daraus ergeben, erfahren Sie in diesem Beitrag.

Doch befassen wir uns zuvor mit der Problematik der klassischen Aufwandsschätzungen in Zeiteinheiten wie Stunden oder Tagen. Die Zeit, die jemand benötigt, um ein Stück Software zu entwickeln, hängt von zahlreichen Faktoren ab. Diese Faktoren sind nicht bzw. nur sehr schwer vorhersehbar, das heißt wir haben keine Kontrolle über sie. Beispiele hierfür sind die Tagesverfassung der Entwickler, die zugrunde liegende Codebasis, Störungen und Unterbrechungen während des Entwickelns, unvorhergesehene technische Schwierigkeiten, etc. um nur ein paar zu nennen. 

‍

Story Points schätzen: Aufwand ist ungleich Dauer

Wenn wir kurz noch bei der Zeit bleiben, ergibt sich durch den Einsatz von iterativer Entwicklung (z.B. Scrum Sprints) ein entscheidender Vorteil: Wir erhalten eine stets gleichbleibende Zeiteinheit. In unserem Fall sind das zwei Wochen, da unsere Teams stets in zweiwöchigen Sprints arbeiten. 

Nun wird es spannend: Wenn die Zeit ohnehin stets gleich ist, wie kann ich dann herausfinden, wie viel Software innerhalb dieser Zeit entwickelt wird? 

Beim Autofahren würden wir das über die Geschwindigkeit erkennen: Diese sagt uns, wie viele Kilometer wir zurücklegen, wenn wir uns eine Stunde lang mit dieser Geschwindigkeit bewegen. Ändert sich diese, so wird auch die zurückgelegte Strecke innerhalb dieser Stunde kürzer oder länger. 

Nicht viel anders verhält es sich beim Entwickeln von Software, mit dem Unterschied, dass wir eben keine Kilometer zurücklegen, sondern Software Code erstellen. Die Menge an Software ist davon abhängig, wie schnell das Team arbeitet bzw. arbeiten kann (mehr dazu später). 

Die Mathematik lehrt uns folgenden Zusammenhang zwischen diesen Größen: 

‍

Geschwindigkeit (v) = Weg (s) / Zeit (t)

‍

Übertragen in die Softwareentwicklung bedeutet dies nun, dass wir Story Points als Maß für den Weg verwenden. Somit tricksen wir die Komplexität aus: denn der tatsächliche Aufwand ist von den oben genannten Faktoren unabhängig, er hängt lediglich von der Geschwindigkeit des Teams ab – diese lässt sich aber messen! 

Stellen Sie sich selbst die folgende Frage: „Wie lange brauche ich von zu Hause bis zum nächstgelegenen Flughafen? Die Antwort lautet ziemlich sicher: „Kommt drauf an...“. Hier fließen viele exogene Faktoren ein, die das Schätzen erschweren, wie zum Beispiel das gewählte Verkehrsmittel, das Wetter, die Tages bzw. Jahreszeit etc. Lautet die Frage aber: „Wie weit ist es von zu Hause bis zum nächsten Flughafen, so werden all diese Faktoren plötzlich irrelevant. Egal ob Schneesturm oder Sonnenschein, der Weg bleibt der gleiche.

Es geht also darum, beim Schätzen daran zu denken, welcher „Weg“ zurückzulegen ist, um das Feature zu entwickeln. Es ist somit nicht relevant, ob das Item vom Besten aller Programmierer oder vom eben eingestellten Praktikanten umgesetzt werden wird – die zu erledigende Arbeitsmenge bleibt gleich. Dies beinhaltet den Entwicklungs- sowie den Testaufwand und alle weiteren nötigen Aktivitäten, die für die Auslieferbarkeit des Items nötig sind, ignoriert aber, wie lange die eigentliche Umsetzung dauern wird.

Anforderungen und Wünsche erfolgreich an Entwickler kommunizieren! 8 Punkte, die Sie bei der Erstellung von User Stories unbedingt wissen sollten.

Story Points sind die Einheit des Aufwands

Diese Einheit lässt sich schwer in absoluten Vergleichszahlen darstellen. Achtung: Vermeiden Sie es tunlichst, diese in Stunden oder Tage umzurechnen. Das wäre so, als würden Sie sagen: Wenn ich mit dem Auto fahre, brauche ich für einen Kilometer zwei Minuten. Dies trifft aber nur für eine ganz bestimmte Geschwindigkeit und somit nur punktuell zu. 

Da es keine absolute Referenzgröße zu einem Story Point gibt, wird sich jedes Team eine eigene Referenz schaffen, die eine rein relative Gültigkeit hat. Das heißt, ein Team wird ein zu schätzendes Stück Software mit ca. doppelt so vielen Story Points abschätzen, wenn alle Teammitglieder der Meinung sind, dass der Aufwand in etwa doppelt so hoch ist. 

Zur langfristigen Planung benötigt man dann nur noch die Velocity, also die pro Sprint umgesetzten Story Points. Nach einigen Sprints lässt sich ein Durchschnitt ableiten und somit in die Zukunft hochrechnen.

‍‍

Welche Faktoren beeinflussen die Velocity?

Natürlich in erster Linie das Entwicklungsteam in Scrum selbst. Keine Frage. Allerdings darf man nicht außer Acht lassen, dass auch zahlreiche weitere Faktoren die Velocity beeinflussen, auf die das Team selbst gar keinen Einfluss hat. 

Daher wäre es ein großer Fehler, die Velocity als Metrik für die Team Performance heranzuziehen. Vielmehr ist es notwendig, stets zu reflektieren, welche Faktoren das Team daran hindern könnten, die Velocity zu steigern und stetig an der Verbesserung dieser zu arbeiten. Hierzu einige Beispiele, die in genau diese Kategorie fallen:

‍

‍Schlechte Infrastruktur

Wie zum Beispiel langsame Hardware, langsame Netzwerkverbindung, zu kleine Bildschirme, zu wenig Zugriffsrechte auf relevante Systeme. Aus diesem Grund sind alle Arbeitsplätze unserer Entwickler mit state-of-the-art Hardware und 34” curved Monitoren ausgestattet. 

‍

Anti-Wohlfühlatmosphäre im Büro‍

Das Arbeitsklima hat eine enorme Auswirkung auf die Performance. Wo die Menschen gerne arbeiten, dort leisten sie auch mehr. 

‍

Ineffiziente Kommunikation‍

Softwareentwicklung besteht zur Hälfte aus Kommunikation. Für den effektivsten und effizientesten Informationsaustausch setzen wir bei Objectbay daher stark auf face to face Kommunikation. 

‍

Zu geringe Verfügbarkeit des Product Owners

Führt zu falschen Annahmen, diese wiederum führen zu unnötigen Nacharbeiten, Zeitverzögerungen oder gar Wartezeiten beim Entwicklerteam. Stellen Sie daher sicher, dass Ihr Produkt Owner genügend Zeit für das zu entwickelnde Produkt zur Verfügung hat. Mindestens 50% der verfügbaren Arbeitszeit (Vollzeit) gilt hier erfahrungsgemäß als Richtgröße.

‍

Unnötiger Druck‍

Es gibt sie, die Menschen, die unter großem Druck auf Hochtouren kommen, allerdings stellen diese eine Minderheit dar. Erhöhter Arbeitsdruck führt in der Regel zu schlechterer Qualität mit allen negativen Folgen die schlechte Qualität nach sich zieht (Stichwort: Mehraufwand, Frustration, Konflikte, etc.)

Wie leitet man nun dennoch die Kosten bzw. den Budgetbedarf ab?

Zeit ist Geld. Daran ändert sich auch durch Story Points nichts. Das heißt, wir leiten die Kosten nicht von der Velocity eines Teams ab, sondern von der Zeit, die vergangen ist. Zum Beispiel durch die Verrechnung nach zeitlichem Aufwand oder durch eine Sprintpauschale. 

Ausgehend von der Gesamtzahl an Story Points für eine zu schätzende Releaseplanung in Scrum (hierfür reicht eine sehr grobe Schätzung in der Regel aus) kann anhand der Velocity eines Teams nun die Anzahl der für die Umsetzung benötigten Sprints berechnet werden.

‍

Ein Beispiel: Die grobe Schätzung eines Softwarepakets ergibt 260 Story Points. Das Team liefert bekannterweise eine Velocity von etwa 20 Story Points pro Sprint. Dies ergibt eine Gesamtdauer von voraussichtlich 13 Sprints. 

‍

Aus der Anzahl von Sprints lassen sich dann anhand der Kosten für einen Sprint die Kosten für das gesamte Vorhaben berechnen.

Frischen Sie Ihr Basiswissen zu User Stories auf. Hier geht's zum Leitfaden „8 Punkte, die Sie bei der Erstellung von User Stories wissen sollten."

‍‍‍