Warum Fünf und Fünf nicht immer gleich sind

Immer, wenn ich Scrum-Teams in den Planning Poker einführe, taucht eine einfache Frage auf. Warum werden manche Probleme mit demselben Story-Point-Wert bewertet, obwohl sie scheinbar völlig unterschiedliche Eigenschaften haben? Dieser Artikel erklärt, warum es nicht sinnvoll ist, Aufgaben mit demselben Story-Point-Wert miteinander zu vergleichen, und wie Story Points Probleme in Größenordnungen gruppieren.

Warum #noestimates keine Option ist

Schauen wir uns zunächst einmal an, warum es keine Option ist, anstehende Aufgaben und Arbeitspakete nicht zu schätzen, wenn man in einem Scrum-Team arbeitet. In einem Kanban Team ist es vollkommen in Ordnung, mit #noestimates zu arbeiten. Kanban ist dafür gedacht, in einer Umgebung eingesetzt zu werden, in der alle Aufgaben mehr oder weniger gleich groß sind. Daher ist keine Schätzung erforderlich. Scrum ist dafür gedacht, in komplexen Umgebungen eingesetzt zu werden, in denen die Größe der Aufgaben stark variieren kann. Deshalb sagt uns der Scrum Guide etwas über die Informationen, die während der Verfeinerung zu einem Product Backlog Item hinzugefügt werden sollen.

Die Verfeinerung des Product Backlogs ist der Vorgang, bei dem Product Backlog-Elemente in kleinere, präzisere Elemente zerlegt und weiter definiert werden. Dies ist eine fortlaufende Aktivität, um Details hinzuzufügen, z. B. eine Beschreibung, Reihenfolge und Größe.

Außerdem, wie soll ein Sprint Planning durchgeführt werden, ohne zu wissen, wie viele Arbeiten im kommenden Sprint geplant werden sollen / dürfen? Da Scrum auf der Theorie der empirischen Prozesssteuerung beruht, verlassen wir uns auf unsere Beobachtungen und unser Wissen über vergangene Ereignisse und den aktuellen Kontext, in dem wir arbeiten. Das bedeutet, dass wir keine Annahmen treffen, wenn wir Entscheidungen treffen, sondern uns auf Fakten verlassen, auch wenn sie uns nicht gefallen.

Daher messen wir ständig die Kapazität des Teams und nutzen die Ergebnisse als Input für unser Sprint Planning. Außerdem schätzen wir die Größe der anstehenden Arbeitspakete, da dies eine fundierte Sprint-Planung ermöglicht. Hier verwenden wir die Kapazität des Teams als Obergrenze für die Menge der zu planenden Arbeit.

Story Points als Schätztechnik

Das führt uns zu der Frage, welche Schätzungstechnik eine gute Wahl für den Einsatz in Scrum-Teams ist. Hier haben Story Points einige eingebaute Eigenschaften, die sie für den Einsatz in Scrum-Umgebungen wirklich gut geeignet machen.

Story Points entkoppeln nicht nur die Diskussion und Schätzung von Aufgaben von der unsäglichen Folklore der Aufwandsschätzungen. Darüber hinaus erlauben Story Points den Teams, die Aspekte Risiko und Unsicherheit in ihre Schätzungen einzubeziehen.

Eine Frage stellt sich jedoch immer, wenn man Planning Poker und Story Points in einem neuen Team einführt. Warum werden manche Aufgaben mit dem gleichen Story-Point-Wert geschätzt, auch wenn sie scheinbar so unterschiedlich sind?

Handhabe von Risiken und Unsicherheiten

Eines der Kernkonzepte der Schätzung mit Story Points ist die Klassifizierung von Problemen in Größenordnungen, was als Problemkomplexität bezeichnet wird. Im Gegensatz zu klassischen Aufwandsschätzungen versuchen wir im Planning Poker nicht, die korrekte Größe eines Problems zu schätzen. Hier versuchen wir, seine Größenordnung zu schätzen. So gehört ein Product Backlog Item, das mit 13 Punkten geschätzt wird, zu einer Gruppe von Problemen, deren Größe zwischen 10,5 und 16,5 Punkten liegt. Dieser Komplexitätswert beinhaltet das Risiko und die Ungewissheit, und die Bereiche werden mit der Größe der geschätzten Probleme größer.

Andererseits müssen sich die Teams dieser Tatsache bewusst sein. Selbst wenn wir die Product Backlog Items nach ihrer Größe gruppieren, können die Workitems einer bestimmten Gruppe immer noch sehr unterschiedliche Größen haben. Es ist also nicht sinnvoll, Workitems einer Gruppe im Nachhinein hinsichtlich ihres tatsächlichen Umsetzungsaufwands zu vergleichen. Es ist immer noch nur eine Schätzung, und die Schätzung ist nur eine Darstellung der Größe des Problems, und nicht seines Aufwands.

Abschließende Gedanken

Obwohl es bequem erscheinen mag, eine #noestimates-Umgebung zu etablieren, ist dies keine Option für Scrum-Teams. Story Points haben sich als das führende Schätzungswerkzeug in agilen Teams entwickelt. Dennoch stellt sich die Frage, warum manche Stories mit demselben Wert geschätzt werden, obwohl sie scheinbar sehr unterschiedliche Eigenschaften haben. Die Story Points-Werte sind keine genauen Maße für die Größe eines Problems. Sie stellen Größenordnungen dar, die Probleme mit ungefähr gleichem Aufwand, Risiko und Unsicherheit zusammenfassen. Diese Ungewissheit wächst mit der Größe der Probleme, und damit wächst auch der Bereich, der von einem einzelnen Wert abgedeckt wird. Dies führt zu dem Effekt, dass die Größe von Problemen innerhalb einer Gruppe unterschiedlich sein kann. Was die Story Points und die damit verbundenen Problemgrößen angeht, so sind fünf und fünf nicht immer gleich.