User-Stories – Schätzen, oder nicht?

USer Stories schätzen, oder nicht?

Das Schätzen von User-Stories ist für viele Teams der blanke Horror. Komplexität oder Aufwand schätzen – wie geht das? Das ist die erste Frage, die sich dem unerfahrenen Teilnehmer bei einem Estimation Meeting stellt.

Braucht ein Team überhaupt Schätzungen?

Der Sinn, hinter dem Schätzen von User-Stories
Der Sinn von Schätzungen ergibt sich aus der Frage: “Wofür benötige ich die Schätzung?”.

“Um zu Messen”, könnte eine Antwort lauten. Ist es eine gute Idee, Werte (Story Points) die auf Prognosen, Vorhersagen, Schätzungen oder Hellsehen basieren, für Metriken zu verwenden?

Messungen sind notwendig, wenn:

  • Der Scrum Master auf Basis der Entwicklungsgeschwindigkeit (Velocity) Engpässe identifiziert.
  • Der Product Owner Releases planen muss.
  • Das Team die Velocity mit der personellen Kapazität verbindet, um die Menge der zu erledigenden Arbeit für einen Sprint zu planen.
  • usw.

Dies sind Gründe, warum User-Stories geschätzt werden.

Wichtig: Keinesfalls darf man agil unerfahrenen Stakeholdern die Performancebewertung der Teams, über die Menge der erledigten Story Points durchgehen lassen.

Schätzen ist Hellseherei, auf die man keine Planung aufbauen kann

Gründe hin oder her. Jeder Plan ist nur so gut wie das Zahlenmaterial, welches dem Plan zugrunde liegt.

Gerade bei neuen Teams fehlt die historische Velocity für eine genauere Planung. Bei den ersten Sprints wird es in der Velocity große Schwankungen geben, die sich erst über die Zeit um einen Mittelwert einschwingen.

Für Pläne bedeutet diese Erkenntnis: Pläne sind am Anfang ungenau und werden erst mit fortschreitender Produktentwicklung immer genauer. Stichwort “Cone of Uncertainty”.

Wie soll ich Komplexität schätzen, wenn ich nicht weiß wie kompliziert das ist?

Komplexität und Kompliziert sind zwei völlig unterschiedliche Dinge, die leider oft in einem Atemzug genannt werden.

Wenn etwas Kompliziert ist, dann ist damit der Grad der Unwissenheit gemeint, der im Bezug auf das Thema herrscht. Ist etwas Komplex, dann ist die Menge der Einzelteile und deren Wechselwirkung untereinander, sowie die Menge an Überraschungen die man erwarten kann, gemeint.

Damit ist die Diskussion im Team schon gesetzt, wie viele Story-Points denn nun diese und jene User-Story beansprucht. Außerdem kennen sich die Tester und die Designer mit der Produktion gar nicht aus. Deshalb können nur Entwickler “richtig” bewerten bzw. schätzen.

So zumindest die landläufige Meinung.

Interessant ist: Story Points weisen keine Einheit auf. Deshalb ist es völlig egal, wie viel Story Points eine Story erhält. 1, 20, 1000. Das einzige was zählt, ist das relative Verhältnis der Story Points zueinander.

Weil das so ist, können auch andere Disziplinen als Produktentwickler gute Schätzungen liefern. Die Diskussionen über die korrekte Anzahl von Story Points, werden bald verschwunden sein.

Geht es auch ohne Schätzen?

Ja. Sie können die Durchflussmenge von User-Storys messen. Der Durchfluss bezieht sich vom Zeitpunkt, wenn eine User-Story ins Backlog kommt, bis zu dem Zeitpunkt wo sie ausgeliefert wird.

Natürlich können Sie auch jeden beliebigen Zeitraum dazwischen, messen. Die Verweildauer einer User-Story in den Zuständen wie “Selected for Development”, “In Development”, “In Testing” usw. können sie ebenfalls messen.

Die Voraussetzungen für dieses Messverfahren ist eine definierte Füllstandshöhe des Backlogs und ungefähr gleich “große” und vertikal geschnittene User-Stories. Allein dies, ist schon eine Herausforderung für sich.

Diese Methode wird, bei der Verwendung von Kanban angewendet.

Meine Empfehlung

Ich bin grundsätzlich für das Schätzen von User-Stories in Scrum Teams. Schätzen birgt viele Vorteile.

Die Abgabe von Schätzungen macht Menschen über den Lauf der Zeit mental stärker und verändert das Selbstbewusstsein. Durch regelmäßige Schätzungen und Planungen wird das Gefühl für Risiken gestärkt. Die damit verbundene Selbstverpflichtung fördert die Übernahme von Verantwortung.

Voraussetzung ist, dass interdisziplinäre Teams User-Stories in Relation setzen können. Das ist einem Team, in einer halben Stunde, leicht zu vermitteln.

Richtig durchgeführt machen die Schätzrunden Spaß und dauern nicht lange. Über die Zeit gereifte Teams, mit denen ich arbeiten durfte, konnten auch mal 100 User-Stories in 60 Minuten schätzen.

Allen Metriken zum Trotz: Denken Sie immer zuerst an die Entwicklung des Teams.

Bleiben Sie erfolgreich!