Für viele Teams, die agil mit Scrum arbeiten, sind Story Points ein Diskussionsthema: „Sollen wir sie verwenden oder nicht, um die Größe von User Stories zu schätzen?“ Das hängt von der jeweiligen Situation ab. Im Folgenden können Sie nachlesen, wann sie für Ihr Team nützlich und wann unnötig ist.
Was sind Story Points?
Story Points sind eine Maßeinheit, die die Relevanz, die Zeit, das Risiko und die Komplexität, auch bekannt als „Aufwand“, die für die Fertigstellung einer User Story erforderlich sind, ausdrückt. Die Verwendung von Story Points erleichtert die Priorisierung der Arbeit am Product Backlog.
Im Allgemeinen werden die Zahlen der Fibonacci-Reihe als Grundlage verwendet. Jede Zahl ist die Summe der beiden vorangegangenen Zahlen. Sie erhalten also: 0, 1, 2, 3, 5, 8, 13… usw. Die Serie wächst also exponentiell. Je höher die Zahl, desto größer der „Aufwand“. In Scrum schätzt man, wie viel „Aufwand“ ein PBI (Product Backlog Item) oder eine User Story bedeutet, und gerade die Tatsache, dass wir im Team wahrscheinlich unterschiedlicher Meinung sind, sorgt für die Diskussion und den Wissensaustausch, den wir brauchen, um zu einer besseren Schätzung zu kommen.
Was sagt der Scrum Guide?
Gibt der Scrum Guide Hinweise zu Story Points? Man sollte meinen, dass es da etwas geben sollte, aber nichts könnte weiter von der Wahrheit entfernt sein. Es ist sehr schön beschrieben, dass die Teammitglieder, die die Arbeit machen, für die Schätzungen verantwortlich sind. Aber wie macht man das? Das hängt von den Teammitgliedern ab.
WIE WAR DAS NOCHMAL? Das ist eine Reaktion, die wir in den Schulungen regelmäßig erleben. Die Menschen finden es natürlicher, Schätzungen in Stunden oder Minuten statt in Story Points vorzunehmen. Und niemand sagt Ihnen, dass Sie es nicht tun sollen (nein, die Scrum-Polizei gibt es nicht).
Aber sehen Sie sich an, was passiert, wenn Sie während eines Sprint Planning Schätzungen in Stunden oder Minuten vornehmen. Den Diskussionsteilnehmern geht es hauptsächlich um mehr oder weniger Stunden: „Ich denke, zwei Stunden. Nun, ich denke, drei Stunden.“ Das Ergebnis ist, dass es keine Diskussionen und keinen Wissensaustausch gibt. Dies kann im weiteren Verlauf des Sprints zu einer Menge Grauzonen und Lärm führen.
Wie funktioniert die Schätzung mit Story Points?
Wenn ich Sie bitten würde, ohne zu googeln zu schätzen, wie viele Meter der Schiphol-Turm hoch ist, hätten Sie wahrscheinlich keine Antwort parat. Und wenn Sie eine Antwort mit großer Unsicherheit geben, liegt sie wahrscheinlich auch weit außerhalb der Richtung der richtigen Antwort.
Mit Story Points nehmen Sie keine Schätzungen in absoluten Einheiten wie Zeit vor, sondern Sie nehmen relative Schätzungen vor. Sie schätzen die neue Arbeit im Vergleich zu einer früheren Arbeit oder zu etwas, das Sie bereits kennen.
Wenn ich Sie fragen würde, ob Sie die Höhe des Wolkenkratzers Burj Kalifa in Dubai mit der Höhe des Schiphol-Towers vergleichen können, wäre die Antwort viel einfacher. Zum Beispiel: wahrscheinlich 8 Mal so hoch. Eine relative Schätzung vermittelt den Menschen eine viel bessere Vorstellung.
Story Points für Product Backlog Items
Die Verwendung von Story Points zur Schätzung von Product Backlog Items kann dasselbe bewirken. Es ist jedoch wichtig, dass alle Teammitglieder sich auf eine Grundlinie einigen können. Stimmen Sie zu, 2 Punkte für ein einfaches (für jeden machbares) Product Backlog Item zu vergeben. Damit ist sichergestellt, dass jeder weiß, welcher „Aufwand 2 Story Points“ entspricht. Wenn man das nicht tut, vergleicht man Äpfel mit Birnen.
Planning Poker
Dies ist sehr einfach, wenn Sie mit Ihrem Team Planning Pokerkarten verwenden. Sie sehen aus wie ein normales Kartenspiel, aber mit der Fibonacci-Folge und einigen zusätzlichen Symbolen wie einer Tasse Kaffee (wenn Sie glauben, dass eine Pause helfen würde) und einem Fragezeichen (wenn Sie es wirklich nicht wissen). Wenn Sie diese Karten verwenden, werfen die Teammitglieder gleichzeitig die Karte ihrer Wahl auf den Tisch, wenn sie mit der Schätzung einer User Story beginnen.
Angenommen, Sie haben fünf Teammitglieder, die die folgenden Karten spielen: 5, 3, 8, 5, 5. Dann ist es eine gute Übung, die beiden Extrema zu fragen. Kurz gesagt, das Teammitglied mit der Schätzung von 3 und das Teammitglied mit der Schätzung von 8 kommen miteinander ins Gespräch.
Warum ist der eine der Meinung, dass es nur 3 Punkte sind, während der nächste nicht weniger als 8 Punkte vergibt? In dieser Diskussion teilen die Teams viel Wissen und sind verletzlicher und transparenter, wenn es um den Inhalt geht, als wenn es um eine Zeitschätzung geht. Das spart eine Menge Lärm. In multidisziplinären Teams trägt dies dazu bei, dass die Menschen schneller T-förmig werden und ihre Erfahrungen und Kenntnisse erweitern, was für das Team und die Organisation wertvoller ist.
Stellen Sie sich die folgende Frage: Bekommt derjenige, der die wenigsten Punkte vergibt, auch den Job? Weil er wahrscheinlich die meiste Erfahrung hat oder es anscheinend am effektivsten machen kann? Die relative Bewertung in Punkten verhindert natürlich nur teilweise ein solches „Gegeneinanderbieten“. Es ist vor allem der Dialog, der wichtig ist, und deshalb ist ein Scrum Master wichtig, um ihn zu erleichtern.
Nachteile von Story Points?
In den folgenden Fällen können Sie überlegen, ob Story Points sinnvoll sind:
- Bugs oder Ad-hoc-Aufgaben. Schätzungen nehmen viel Zeit in Anspruch, und möglicherweise können Sie das Problem in der veranschlagten Zeit lösen.
- Ohne einen guten Scrum Master kann es zu endlosen Diskussionen kommen.
- Die Story Points unterscheiden sich von Team zu Team, was einen Vergleich erschwert und manchmal zu falschen Schlussfolgerungen führt.
- Stakeholder sollten in die Story Points einbezogen werden, da sie oft noch in Zeiträumen denken.
Also, Story Points verwenden oder nicht?
Die meisten Teams, die mit Story Points arbeiten, sind gerne bereit, mit dem Team im Vorfeld genau zu erkunden, was die komplexe Aufgabe beinhaltet. Auf diese Weise kann das Wissen angemessen demonstriert und vermittelt werden.
Denn bei allen Aufgaben, aber insbesondere bei komplexen Scrum-Aufgaben, ist die Schätzung eine Prognose. Nichts weiter als das. Die Arbeit mit Story Points passt daher perfekt zur empirischen Arbeit innerhalb von Scrum. Wir schätzen und prüfen sorgfältig. Wir sind transparent darüber, was wir wissen und was nicht, und können überprüfen, ob es so läuft, wie es für den Kunden wertvoll ist. Wenn nötig, passen wir sie an.
Aber sind Story Points obligatorisch? Nein, das sind sie nicht.
