Story Points, nicht Requirement Points

Bild: Freegreatpicture / Max Pixel - CC0 1.0

Es gibt im agilen Umfeld Themen die immer weitere Informationen preisgeben, je mehr man sich in sie vertieft. Story Points gehören auf jeden Fall dazu, mit ihnen kann man wesentlich mehr machen als es auf den ersten Blick scheint. Bevor es darum geht aber zunächst zum Grundsätzlichen: Story Points sind eine neutrale Schätzgröße, mit der man den Umsetzungsaufwand von Anforderungen schätzen kann ohne berücksichtigen zu müssen wer genau die Umsetzung vornehmen wird. Mehr dazu hier. Es bleibt allerdings eine Frage - warum dann der wunderliche Name? Wäre "Requirement Points" nicht passender?

Der Grund für die Benennung liegt darin, dass mit Story Points ursprünglich im Extreme Programming User Stories geschätzt wurden. Ein kurzer Exkurs: User Stories sind Anforderungen in einfacher Sprache, die (End)Anwender, Use Case und Business Value in einem Satz benennen. Mehr dazu hier. Diese exklusive Verwendung gibt es heute kaum noch, mit Story Points werden nicht mehr nur User Stories geschätzt sondern alle anderen Anforderungen genauso. Manche Teams nennen auch einfach jede Anforderung User Story, allerdings ist das dann nicht mehr das was damit beabsichtigt ist.

Um Missverständnissen vorzubeugen, Story Points als generische Schätzeinheit für alle Anforderungen zu verwenden ist nicht per se schlecht. Trotzdem kann es Sinn machen ihre Benutzung auf User Stories zu beschränken. Denn: wenn der (End)Benutzer derjenige ist für den Software gebaut wird, und wenn alles was er damit tun kann ein Use Case ist der sich mit User Stories abbilden lässt, dann kann (und sollte) man bei allem was keine User Story ist die Sinnfrage stellen.

Natürlich verfolgen auch "Nicht-User Stories" einen Zweck. Code wird bereinigt, Lastfähigkeit hergestellt, Architektur wird geradegezogen, Tests werden automatisiert und halbfertige Funktionen werden komplettiert. Der Punkt ist nur der - das kann man auch gleich machen, als Teil einer User Story die benutzbare Funktionalität liefert. Diese Tätigkeiten auf die lange Bank zu schieben ist nichts weiter als das Anhäufen organisatorischer Schulden, wodurch alles länger dauert und teurer wird.

Wenn also alles was dem Anwender Nutzen bringt als User Story formuliert werden kann, und wenn praktisch alle nichtfunktionalen Anforderungen in diesen User Stories unterkommen können, dann kann man auch sagen: User Stories sind das was Mehrwert liefern, der gesamte Rest ist Waste. Unsinnige Arbeit - oder die Folge unsinniger Arbeit.

Die Anwendung von Story Points nur auf User Stories bedeutet in diesem Fall, dass deren Durchschnittsmenge pro Sprint, die Velocity, nur Mehrwert erzeugende Arbeit anzeigt und den Rest ignoriert. Für Teams kann das sehr wertvoll sein. Ihre Velocity zeigt nicht mehr womit sie Zeit verbracht haben (🡢 Output) sondern womit sie Wert generiert haben (🡢 Outcome). Und mit dieser Erkenntnis können sie daran arbeiten den Output zu senken und den Outcome zu erhöhen.

Die Negativseite dieses Ansatzes ist natürlich, dass in Teams mit vielen "Nicht-User Stories" die Velocity nicht mehr beim Planen hilft. Allerdings - dort wo es viele organisatorische Schulden gibt ist Planung ohnehin nur eingeschränkt möglich, man bleibt zu häufig in den Spätfolgen der eigenen Versäumnisse hängen.