Montag, 16. Oktober 2017

Story Points

Bild: Publicdomainpictures - CC0 1.0
Es gibt eine Grundsatzdebatte die bei fast jeder Scrum-Einführung aufkommt, und zwar die um die Story Points. Muss das sein? Warum braucht man die? Warum schätzen wir nicht in Personentagen, wie jeder andere auch? Alle diese Fragen sind berechtigt und müssen beantwortet werden wenn diese Methode vom Team akzeptiert und angewandt werden soll. Story Points sind nämlich keineswegs Teil von Scrum, sie sind lediglich eine ursprünglich aus dem Extreme Programming kommende good Practice und können von jedem Team auch weggelassen werden.

Um zu verstehen warum man es zwar kann aber nicht sollte bietet sich ein Gedankenspiel an. Ein Team schätzt eine Anforderung während eines Backlog Refinements und benutzt dabei Personentage als Metrik. Die Schätzung ist aus der Sicht aller Beteiligten auch einigermassen realistisch. In einem der folgenden Sprints beginnt die Umsetzung, jetzt stellt sich aber heraus, dass die geschätzte Zeit nicht stimmt und die Umsetzung deutlich länger oder kürzer dauert. Fast jedes Team wird an dieser Stelle bestätigen, dass es diese Situation aus eigener Erfahrung kennt. Woran kann das liegen?

Ein häufiger Grund ist, dass die einzelnen Teammitglieder unterschiedliche Kenntnisse und Erfahrungswerte in verschiedenen Themengebieten haben, was dazu führt, dass unterschiedliche Personen unterschiedlich lang mit der Umsetzung der selben Aufgabe beschäftigt wären. Jacob bräuchte z.B. sechs Tage für das Implementieren einer Upload-Funktion, Jennifer dagegen nur drei. Da die Aufwandsschätzung aber lediglich den Konsens oder Mittelwert eines Teams darstellt kann sie im Einzelfall nur danebenliegen, bestenfalls um Stunden, schlimmstenfalls um Tage.

Aber kann man dann nicht einfach im voraus festlegen wer welche Aufgabe übernimmt? Im Prinzip ja, allerdings zu einem Preis. Wenn Arbeitspakete von Beginn an einer Person zugeordnet sind nimmt man sich Fexibilität und riskiert, dass diese Person zu einem Flaschenhals werden kann der ggf. alle anderen verzögert. Der Busfaktor (das Risiko, dass der Ausfall einer einzigen Person Auswirkungen auf alle anderen hat) steigt und zuletzt wird es deutlich schwerer die Teammitglieder durch Hands On-Erfahrungen mit neuen Themem in Richtung T-Shape zu entwickeln.

Durch die Nutzung von Story Points kann ein Grossteil dieser negativen Effekte kompensiert werden, und zwar einfach dadurch, dass sie eine neutrale Schätzgrösse bilden. Das Team kann sie weiterhin gemeinsam schätzen, aber der Schätzwert von z.B. fünf Story Points bedeutet dann eben für Jacob sechs Tage und für Jennifer drei. Entgegen einem häufigen Vorurteil muss man dafür auch nicht die Prognosefähigkeit für die nächste Zeit aufgeben, denn in der grossen Zahl mitteln sich die Unterschiede und man kann mit einem Durchschnittswert von Story Points pro Sprint planen, der Velocity.

Es gibt darüber hinaus noch weitere Argumente für Story Points, etwa die Veranlagung des menschlichen Gehirns zum relationalen Schätzen oder die dadurch möglichen Moderationstechniken, wie z.B. Planning Poker. Wenn all das einem Team erklärt wird entscheidet es sich in vielen Fällen von sich aus dafür dauerhaft mit dieser Metrik zu arbeiten, selbst wenn es zu Beginn die oben genannten Fragen gestellt hat.

Related Articles