Story Points stellen weder Zeit noch Menge noch Wert dar

Die Kennzahl „Story Points“ ist eine rein fiktive Größe, die nicht ohne Weiteres mit beobachtbaren „realen“ Phänomenen der Umwelt in Beziehung gesetzt werden kann. Was soll diese Kennzahl darstellen, wie kann ein Team sie festlegen und wo lauern die Stolperfallen?

Zu welchem Zweck wurden Story Points erfunden?

Oft höre ich, dass Story Points jenen Wert darstellen, den ein Team in einem bestimmten Zyklus, zum Beispiel während eines Sprints, mit seiner Lieferung erzeugt. Manchmal soll es auch eher der Aufwand für die umzusetzenden Dinge sein oder die Anzahl der Features oder Produktinkremente, die ein Team pro Zyklus geschafft hat. Nein, nein und nochmals nein.

Story Points wurden erfunden, um Teams einen guten Indikator für ihre (Weiter-)Entwicklung zu geben. Bei Leistungsunterschieden bzw. -schwankungen innerhalb eines Teams und zwischen verschiedenen Teams ermöglichen Story Points eine gewisse Vergleichbarkeit. Das funktioniert nicht mit scheinbar objektiven und teamübergreifenden Kennzahlen, sondern nur mit solchen, die sich direkt auf ein Team selbst beziehen. Innerhalb des Teams können diese Werte dann über die Zeit in Relation zueinander gesetzt werden.

Dazu gebe ich gerne ein Beispiel: Wenn zwei verschiedene Teams unterschiedliche Leistungen erbringen und von einem Sprint zum nächsten je um eine Zeiteinheit schneller werden oder um eine Mengeneinheit mehr liefern, ist das nicht miteinander vergleichbar. Es sagt auch nichts über die Entwicklung der Leistung dieser Teams aus.

Was aber ist nun vergleichbar?

Wenn jeweils beide Teams ihre Zeit- oder Mengeneinheiten von einem Sprint zum nächsten halbieren bzw. verdoppeln und die jeweils teaminternen Bewertungsmaßstäbe zu Story Points gleichgeblieben sind, haben sie die gleiche Leistungssteigerung hingelegt. Auf die gleichbleibende Bewertungsgrundlage komme ich gleich noch einmal zu sprechen.

Genau das soll mit Story Points gemessen werden: Story Points sind kein Kampfmittel, mit dem Teams in einem Wettbewerb gegeneinander antreten. Deshalb dürfen Story Points auf gar keinen Fall teamübergreifend festgelegt werden. Jedes Team sollte seine eigene Bezugsgröße haben.

Das Fiktive an dieser Kennzahl „Story Points“ mag uns auf den ersten Blick vielleicht verwundern. Allerdings nutzen wir solche fiktiven Kennzahlen tagtäglich, nämlich dann, wenn wir uns über Zeit-, Mengen- oder Längenangaben austauschen. Dazu komme ich nun.

Wie lässt sich die Kennzahl festlegen?

Um eine rein fiktive Kennzahl festlegen zu können, braucht das Team, für das diese Kennzahl Gültigkeit haben soll, zunächst eine erste Definition. Das ist die notwendige Basis, auf die sich die Teammitglieder schnell einigen können. Deshalb sollte zum Beispiel nicht jener Wert herangezogen werden, den das Team für den Kunden anhand der Produkte schafft, die es baut. Warum? Diese Kennzahl hat hohe subjektive Anteile.

Was könnte sich als Grundlage eignen?

Wählen wir zum Beispiel den Aufwand in Stunden, den das Team benötigt, um eine User Story umzusetzen. In diesem Fall könnte das Team festlegen: 1 Story Point = x Stunden. Eine andere Grundlage könnte die Anzahl an Features sein, die im Rahmen einer User Story umgesetzt werden: 1 Feature = x Story Points. Allerdings sollte es im Team eine klare gemeinsame Sichtweise dazu geben, was genau ein Feature ist. Ohne Einigung ist diese Basis eher nicht passfähig.

Das Team könnte aber auch eine ganz bestimmte User Story hernehmen und für diese die Mächtigkeit schätzen – also die Komplexität, die Anzahl der Features etc. Dieser User Story werden dann Story Points zugewiesen und sie dient ab sofort als Referenz für das Schätzen aller weiteren User Storys: Die zu schätzenden User Storys werden damit verglichen und als Ergebnis werden sie mit entsprechenden Story Points versehen. Allerdings muss diese Referenz-User-Story stabil sein – d. h., sie darf sich nicht von Sprint zu Sprint ändern. Leider höre ich häufig, dass die Bewertungsgrundlage für die Story Points ständig geändert wird. Das ergibt keinen Sinn: Wir legen ja auch nicht vor jedem Fußballspiel aufs Neue fest, wie sich eine Sekunde bemisst. Das wäre fatal: Zwar würde jedes Spiel 90 Minuten dauern, aber die Mannschaften müssten trotzdem unterschiedlich lange spielen.

Sobald das Team für sich eine Definition der Story Points festgelegt hat, sollte diese also stabil bleiben und allen Teammitgliedern beim Schätzen stets präsent sein – aber einzig und allein als Bewertungsgrundlage, nicht um damit qualitätsbezogene Aussagen zu treffen.

Warum brauchen wir eine stabile Grundlage?

Ziehen wir die Zeit als Beispiel heran. Die Zeit als Kennzahl – die erst einmal rein fiktiv ist, was uns gar nicht mehr bewusst ist – muss zunächst über eine objektive Bezugsgröße definiert werden (siehe etwa hier):

Die Sekunde ist das 9.192.631.770-fache der Periodendauer der dem Übergang zwischen den beiden Hyperfeinstrukturniveaus des Grundzustandes von Atomen des Nuklids Cs-133 entsprechenden Strahlung.

In dem Moment, in dem sich alle Menschen auf diese Grundlage zum Messen von Zeit einigen und diese Grundlage auch stabil bleibt, muss sie nie mehr hervorgekramt werden, wenn man die Zeit misst und sich gemeinsam daran ausrichtet. Man muss die genaue Definition einer Sekunde nicht einmal kennen, um zu wissen, was eine Sekunde bedeutet. Ähnlich verhält es sich mit der Leistung eines Teams, die anhand der fiktiven Kennzahl Story Points gemessen wird.

Ändern wir diese Grundlage und fehlt noch dazu das gemeinsame Verständnis, dann erfüllt die Kennzahl nicht mehr ihren Zweck – ja das Anwenden der Kennzahl wird sogar ad absurdum geführt. Stellen wir uns vor, ich wäre in der Lage, die Periodendauer eines anderen Atoms als Definition für eine Sekunde herzunehmen: Die Verständigung mit anderen Menschen würde mir wohl extrem schwerfallen. Eine Sekunde wäre für mich nicht mehr das Gleiche wie für andere Menschen.

Ähnlich verhält es sich mit den Story Points. Dazu komme ich jetzt. 

Was ist zu beachten?

Stellen Sie sich vor, ein Team bekommt die Order, im nächsten Sprint die Velocity (Geschwindigkeit) zu erhöhen. Die Velocity eines Teams wird mit folgender Formel gemessen:

Velocity = Summe aller Story Points der erledigten Storys

Welche Vorgehensweise ist wohl die effizienteste und risikoärmste, um der Order gerecht zu werden? Das Team könnte einfach die Basis für die Ermittlung von Story Points verändern, indem es diese beispielsweise mit dem Faktor 2 multipliziert. Was passiert? Automatisch erhöht das Team per Berechnung seine Velocity, während sich für die Umwelt rein gar nichts geändert hat. Das Team liefert nicht mehr als zuvor, aber die Kennzahl Velocity hat sich verbessert. Genial, oder? Schwierig wird es, wenn Story Points herangezogen werden, um vertragliche Verpflichtungen zu erfüllen. Aus Teamsicht lässt es sich dann sehr leicht Geld verdienen und Verträge erfüllen.

Das ist so, als müsste ich bei mir zu Hause ganz alleine einen 100-Meter-Lauf absolvieren: Ich würde einfach die Definition der Sekunde ändern, nämlich genau so, dass ich für mich eine Sekunde verdopple und das für mich die neue Sekunde ergibt. Wow! Ich würde den Weltrekord knacken, denn 100 Meter in 6 bis 7 Sekunden wären ab sofort kein Problem mehr für mich.

Also Obacht beim Anwenden der Kennzahl Story Points.

Titelbild: Unsplash License, Maria Bobrova

Agile Toolbox
Scrum
Schätzen
Scrum-Begriffe
Conny Dethloff
March 24, 2021

Table of content

Diesen Beitrag teilen

Das könnte auch interessant sein:

Agile Coach
Agile Management
Agile Organization
Agile Prinzipien
Agile Toolbox

FRAGE: Warum macht ihr eigentlich kein SAFe?

Agile Management
Agile Organization
Agile Prinzipien
Agile Toolbox
Transformation

FRAGE: Was kostet eine agile Transformation?

Agile Management
Agile Organization
Agile Toolbox
Leadership
Agiles Lernen

FRAGE: Welche Rolle spielt Training?

Agile Coach
Agile Management
Agile Organization
Agile Prinzipien
Agile Toolbox

FRAGE: Wer sind die Top 10 agilen Unternehmensberatungen?

Agile Management
Agile Organization
Agile Tools
Agiles Management
Leadership

FRAGE: Wie viel bringt die Investition? Was ist der Business Case dahinter?

Agile Management
Agile Organization
Agile Prinzipien
Agile Toolbox
Führung

FRAGE: Welche sind häufige Herausforderungen, die ihr beim Kunden löst?

Agile Management
Agile Organization

FRAGE: Warum sollten wir mit borisgloger arbeiten?

Agile Management
Agile Organization
Agiles Management
Transformation

FRAGE: Wie viel kostet eine Beratung und ist es wirklich rentabel bei borisgloger?

Agile Prinzipien
Agile Toolbox
Projektmanagement

The Lie Behind the Parable of the Golf Balls and the Jar

Video
Change
Digitale Transformation
Hardware
Agile Organization

Agile in Industrial Automation: The Digital Transformation of Yokogawa

Versicherung
Neues Arbeiten
Führung
Agile Prinzipien
Kundenfokus

Kundenzentrierte Versicherung: Kann ein agiles Projekt die Organisation retten?

Versicherung
Change
Digitale Transformation
Agile Prinzipien
Kundenfokus

Agilität in den Vertrieb bringen – für Versicherer sinnvoll

Versicherung
Agile Prinzipien
Kundenfokus
Agile Toolbox
Produktentwicklung

BizDevOps in der Versicherungsbranche – Wie multidisziplinäre Teams wirklich besetzt sein sollten

Versicherung
Agile Prinzipien
Kundenfokus
Neues Arbeiten
Meetings

Undercover Agile für Versicherer: 5 agile Praktiken für Ihr klassisches IT-Projekt

Versicherung
Change
Digitale Transformation
Agile Prinzipien
Kundenfokus

IT-Projekte in der Versicherungsbranche – Das Rennen um die Time-to-Market

Team
Neues Arbeiten
Agile Prinzipien
Selbstorganisation
Social Skills

Umgang mit Fehlern & Diversität – Erfolgreiche agile Teams #2

Team
Neues Arbeiten
Agile Toolbox
Produktentwicklung

Das Geheimrezept von High-Performance-Teams

Team
Arbeiten bei borisgloger consulting
Agile Prinzipien
Freiwilligkeit
Selbstorganisation

Konsent und offene Wahl: 2 Prinzipien aus der Soziokratie, die jedes agile Team gebrauchen kann

Team
Neues Arbeiten
Meetings
Social Skills

Der agile Adventkalender

Team
Agile Toolbox
Scrum
ScrumMaster-Praxistipps
Agile Prinzipien

Selbstorganisation der Teams fördern: Ask the team!

Team
Agile Toolbox
Design Thinking

Who Recognizes the Truly Good Ideas?

Team
Agile Organization
Transformation

Pizza Is Not Dead, and Neither Is Agility

Scrum4Schools
Neues Arbeiten
Führung
Life
Social Skills

Trauen wir unseren Kindern mehr zu – auch in der Schule!

Scrum4Schools
Change
Agiles Lernen
Neues Arbeiten
Remote Arbeiten

Eine Scrum4Schools-Projekt-Rückschau mit Physiklehrer Ivan Topic

Scrum4Schools
Mehr Formate
Interview
Nachhaltigkeit

Mit Scrum4Schools dem Weltraum auf der Spur

Scrum4Schools
Change
Agiles Lernen

Scrum4Schools - ein Projekt nimmt Fahrt auf

Scrum4Schools
Agile Schulentwicklung
Agile Toolbox

Technik im Alltag - Scrum4Schools zu Gast in Langenzersdorf

Projektmanagement
Agile Toolbox
Scrum
Scrum-Begriffe
ScrumMaster-Praxistipps

Sprechen Sie Agile? Den klassischen Projektplan in die agile Welt überführen

Projektmanagement
Agiles Management
Agile Toolbox
Scrum
Enterprise Scrum

Das Management in Scrum

Projektmanagement
Change
Digitale Transformation

Agilität in der Logistik oder: Liefern wie Amazon

Projektmanagement
Agile Toolbox
Scrum

Meilensteine und Scrum

Portfoliomanagement
Project management

Too many projects? Portfolio management simplified

Neues Arbeiten
Mehr Formate
Agile Toolbox
Scrum
Scrum Values

Wie agiles Arbeiten die Kommunikation aus der Selbstverständlichkeit holt

Neues Arbeiten
Change
Agiles Lernen
Mehr Formate
Audio

New Learning heute für das New Work von morgen – mit Angelika Weis

Neues Arbeiten
Change
Soziale Innovation

New Work Experience 2019 – ein Erfahrungsbericht

Neues Arbeiten
Audit
Change

Agil im Audit: das Starter-Kit

Neues Arbeiten
Agile Toolbox
Scrum
Scrum4Schools
Agile Prinzipien

Scrum4Schools: Lernen für die Zukunft

Neues Arbeiten
Agile Toolbox
Scrum
Scrum Meetings
Retrospektive

Arbeiten wir uns gesund!

Neues Arbeiten
Agile Toolbox
Scrum
ScrumMaster-Praxistipps

Who should be in (agile) HR?

Neues Arbeiten
Agile Toolbox
Scrum
Scrum Values

Glauben Sie an die Seele Ihrer Firma?

Neues Arbeiten
Agile Toolbox
Scrum
Product Owner
ScrumMaster-Praxistipps

Produktivität auf Irrwegen: "Führen wir schnell mal Scrum ein!"

Neues Arbeiten
Agile Prinzipien
Selbstorganisation
Social Skills
Team

Freiwilliges Teilen von Wissen – Erfolgreiche agile Teams #5

Neues Arbeiten
Agile Prinzipien
Selbstorganisation
Social Skills
Team

Doing vs. Being Agile – Erfolgreiche agile Teams #1

Neues Arbeiten
Agile Prinzipien
Selbstorganisation
Social Skills
Team

Freude bei der Arbeit & Sustainable Pace – Erfolgreiche agile Teams #3

Neues Arbeiten
Agile Prinzipien
Selbstorganisation
Social Skills
Team

Anpassungsfähigkeit & schonungslose Offenheit – Erfolgreiche agile Teams #4