#projects

Storypoints - Ein faires Werkzeug für faire Preise

Die Idee von "Manntagen" ist nicht nur nicht länger zeitgemäß, sondern hat auch in der Softwareentwicklung wenig verloren. Aber warum ist das so? Weniger Stunden sollte doch weniger Kosten bedeuten, oder etwa nicht?

Storypoints - Ein faires Werkzeug für faire Preise
Valentin Jäch
Gründer / Human Resources bei Deckweiss

Erzähl uns deine Geschichte

Ein Storypoint ist ein Punkt einer Story - zum Beispiel Deiner Story. Ja genau, jeder hat eine Story zu erzählen. Sei es die Geschichte von deiner letzten Rad-Tour oder die Geschichte zu deinem Vorhaben/Projekt die du uns erzählen kannst.

Oft können Geschichten von einem Vorhaben aber auch sehr groß und unübersichtlich sein. Deshalb macht es Sinn, die gesamte Story in kleinere Etappen/Kapitel zu unterteilen und auch dort wieder einzelne Schritte zu setzen. Hinter jedem Schritt steckt aber nicht immer gleich viel Aufwand. Diesen Aufwand kann man dann bereits im Voraus abschätzen, je granularer und kompakter die Story in einzelne Etappen heruntergebrochen wird, desto genauer wird auch die Schätzung werden. Wenn du uns beispielsweise erzählst, dass du eine App entwickeln lassen möchtest, wirst du uns von allen Ideen und Funktionen erzählen, die man mit deiner App machen kann. Jede dieser Ideen und jedes Feature wird dann einer User-Story (= Etappe/Schritt der gesamten App, mehr zu User-Stories findest du hier: https://www.deckweiss.at/post/wie-bringe-ich-meine-software-idee-zu-papier) zugeteilt, die z.B. lauten kann: "Ich möchte mich als User einloggen können".

Schätzung nach Stunden

Wir könnten jetzt aus all den User-Stories die wir aus der gesamten Story gebildet haben, eine Schätzung für den gesamten Aufwand in Stunden erbringen. Warum machen wir das nicht?

Ganz einfach: es wäre unfair! Für uns, für dich, für den Markt - es wird so gut wie immer für jemanden unfair sein.

Ich erkläre es an einem einfachen Beispiel: Angenommen du beauftragst uns, dass wir deine App programmieren sollen und wir stellen dafür ein Team aus 5 Experten zusammen, die die schnellsten und besten Programmierer weit und breit sind. Die App wäre in Rekordzeit umgesetzt und wir schätzen deshalb wenig Zeit für die Umsetzung ein - bedeutet wenig Kosten für dich.

Angenommen das Team, welches wir zusammenstellen, besteht aus 3 Junior-Entwicklern die neu bei uns angefangen haben und 2 Senior-Entwicklern die unsere Neuen coachen. Wir würden sehr viel Zeit für dein Projekt einschätzen, da wir einberechnen, dass die Junior-Entwickler eingeschult werden müssen, wahrscheinlich noch einige Fehler machen werden und einfach noch einiges zu lernen haben. Es würde länger dauern bis die App fertig ist - bedeutet viel Kosten für dich.

Schlussendlich wird aber in beiden Fällen die gleiche Leistung erbracht, warum sollten dabei unterschiedliche Kosten anfallen? Bei Variante A würden wir wahrscheinlich den Markt stark unterbieten was unfair für den Markt ist und auch für uns unfair, weil wir wenig für viel Leistung bekommen. Bei Variante B würden wir dich "berauben" indem wir viel verrechnen für den Mehraufwand, den die neuen Entwickler anfangs haben. Was ist nun ein Ansatz für eine faire Lösung? Treffen wir uns in der Mitte? Klingt vielleicht erstmal gut, ist aber auch wieder ungerecht. Die Mitte von zwei unfairen Varianten, ist ebenfalls nicht gerecht, da sie ja abhängig von den anderen beiden Varianten ist. Das heißt, wenn wir beispielsweise die Junior-Entwickler schon etwas eingeschult haben, würden diese schneller arbeiten und die Mitte würde sich in Richtung Senior-Entwicklern verschieben. Unsere Lösung heißt: Story-Points.

Wer oder was ist ein Story-Point?

Beginnen wir mit einem kleinen Beispiel. Sagen wir, es gibt 2 User-Stories:

  1. Als User möchte ich mich über meine E-Mail Adresse registrieren können. (5 Story-Points)
  2. Als User möchte ich mich über meine E-Mail Adresse einloggen können. (2 SP)

Story 1 ist weitaus komplexer, da man hier einen neuen Benutzer anlegen muss und das Formular zur Registrierung sicher aufwendiger ist als das Formular für den Login. Deshalb erhält es von uns auch dementsprechend mehr Story-Points. Angenommen man lässt diese Stories von den Entwicklern umsetzen, so hat der Senior, sagen wir, 2 Stunden benötigt. Der Junior hingegen 8 Stunden, also die 4-fache Zeit. Verrechnet werden bei uns aber im Endeffekt exakt die Anzahl der Story-Points, unabhängig davon wie viel Zeit der jeweilige Entwickler im Endeffekt dafür benötigt hat.

Ein Story-Point ist also ein Gewichtungspunkt mit dem wir den Aufwand und die Komplexität einer User-Story (einzelne Etappe/Schritt deiner gesamten Story) bewerten können. Er gibt an, wie Komplex etwas umzusetzen ist. Völlig unabhängig davon, wer diese User-Story umsetzt oder womit sie umgesetzt wird. Die Anzahl der jeweiligen Story-Points pro User-Story lassen sich definieren, anhand von User-Stories, deren Komplexität man sehr genau abschätzen kann und die somit Richtwerte/Referenzwerte bilden. Alle weiteren User-Stories werden mit einer Anzahl an Story-Points versehen, die relativ zu diesen Richtwerten ist. Wissen wir z.B. dass die Umsetzung des Logins die wohl einfachste Aufgabe der App sein wird und besitzen wir dieses wissen auch noch über weitere andere User-Stories, so schätzen wir all restlichen User-Stories relativ dazu ein und vergeben Story-Points, die einem relativen Aufwand dazu entsprechen.

Zusatz: 1 - 2 - 3 - 5 - 8 ...

Wenn du diese Zahlenfolge in der Überschrift siehst, denkst du wahrscheinlich - die können nicht mal richtig zählen. Stimmt nicht ganz - ich hoffe dass wir das können, aber was wir auf jeden fall kennen, ist die Fibonacci-Folge. Das ist eine Zahlenfolge, deren folgende Zahlen sich immer aus den beiden Vorgängern bilden, also bei 5 haben wir z.B. zuvor 2 und 3 - und 2 + 3 ergibt bekanntlich 5. Wer sich näher darüber informieren will, findet dazu hier eine Erklärung. Diese Folge wird üblicherweise zur Vergabe der Story-Points verwendet. Wie wir nämlich schon zuvor erzählt haben, ist es umso einfacher etwas abzuschätzen, je granularer oder kompakter es heruntergebrochen werden kann. Kann man etwas nur sehr grob oder eben ungenau definieren, wird auch die Schätzung ungenauer und diese Ungenauigkeit lässt sich mit der Fibonacci-Folge gut abbilden, da sie nach oben hin immer schneller steigt und größer wird.

Wie kommt der gesamte Projektumfang zustande?

Nach und nach schätzen wir immer(!) im Team mit mindestens 2 Personen die Etappen (User-Stories) deiner Story, die du uns erzählt hast. Am Anfang definieren wir, wie oben bereits erklärt, die Referenz-Stories. Relativ dazu betrachten wir dann alle anderen User-Stories deines Projekts und schätzen für jede Story ihre Story-Points (also eigentlich ihre Komplexität) ein. Das machen wir indem wir sie mit den Referenz-Stories, bzw. den bereits geschätzten Stories vergleichen und relativ dazu auf ein Ergebnis kommen. Vielleicht ein kurzes Beispiel dazu:

Wir wissen, dass der Login einen Aufwand von 2 SP (Story-Points) hat und die Registrierung 5 SP. Als nächste User-Story betrachten wir beispielsweise "Als User möchte ich das Impressum einsehen können.". Vergleichen wir die Anzeige einer Impressum-Seite (fixen Text auf einer Seite anzeigen) mit der Komplexität des Logins (Username und Passwort überprüfen, Login-Formular erstellen, auf Sicherheit achten, ...), merken wir, dass der Login aufwändiger ist. Somit vergeben wir dem Impressum in diesem Fall einen Story-Point, jedenfalls weniger Story-Points als der Login hat.

Die Summe aller Story-Points ergibt dann im Endeffekt den gesamten Projektumfang. Das kann beispielsweise so aussehen, dass wir gesamt 200 Story-Points als Ergebnis der Schätzung bekommen. Daraus lässt sich dann ein Preis berechnen. Pro Projekt hat 1 Story-Point einen unterschiedlichen Preis, da 1 Story-Point nicht in jedem Projekt gleich viel Komplexität bedeutet.  Wie zuvor gehört, bilden sich die Story-Points ja anhand von Richtwerten, die zu Beginn der Schätzung definiert werden und da kann in einem Projekt der Login beispielsweise 2 Story-Points erhalten, in einem anderen Projekt aber 5, weil hier alle anderen User-Stories beispielsweise viel einfacher zu erfüllen sind.

Was bringen mir diese Story-Points?

Angenommen du hast dein Projekt schätzen lassen und bekommst ein Angebot für 500 Stunden. Du kommst relativ früh darauf, dass du gerne Features im Projektumfang austauschen möchtest gegen andere Features, die du gerne am Ende des Projekts umgesetzt hättest. Basiert das Angebot auf Stunden und schätzt der Auftragnehmer das neue Feature nicht zu 100% gleich wie das alte Feature ein, wird sich zwingendermaßen der Preis des Projekts ändern. Kommst du mit deinem Projekt zu uns, schätzen wir dir einen gesamten Umfang in Story-Points, sagen wir 200. Du bekommst für diesen Umfang einen Preis genannt und weißt wie viele Story-Points darin inbegriffen sind. Wenn du nun Features austauschen möchtest, ist es uns völlig egal, wie viele du tauschen möchtest und ob du beispielsweise 1 komplexes für 3 einfache tauschen willst - solange im Endeffekt wieder ein Umfang von 200 Story-Points dabei rauskommt, bleibt der Preis gleich. Und auch neue Features, die zusätzlich hinzu kommen, sind sehr schnell und effizient geschätzt, da wir den Aufwand sehr gut relativ zum Rest beurteilen können und somit schnell eine passende Zahl an Story-Points finden werden und auch den Preis nennen können.

Wieviel Zeit wir intern dann für das Projekt schätzen, um unsere Ressourcen zu planen und ob wir diese dann auch exakt einhalten oder nicht, bleibt uns überlassen und wirkt sich nicht auf dich aus.

Wie vorhin schon beschrieben, ist es in unseren Augen auch die fairste Methode für eine langfristige Zusammenarbeit.

Wenn du dich näher darüber informieren möchtest oder dich über unsere Herangehensweise unterhalten möchtest, melde dich jederzeit gerne direkt bei uns!

Artikel teilen