User Storys schätzen ist einfach

User Storys schätzen, ist für viele Teams der blanke Horror. Neben hitzigen Diskussionen und sogar Streit führt das Schätzen von User Storys oft zu faulen Kompromissen. Was ist denn bitte Komplexität? Warum soll kein Aufwand geschätzt werden? Oft rechnen Developer ohnehin, unbewusst, mit Tagen und Stunden.

Warum und wie ein agiles Team User Storys schätzen kann, beschreibt dieser Artikel.

Muss ein Team denn User Storys schätzen?

Der Sinn beim Schätzen von User Storys ergibt sich aus der Frage: “Wofür benötige ich die Schätzung?”.

Antwort: Um zu messen.

Ist es eine gute Idee, Werte mit User Story Points, die auf Prognosen, Vorhersagen, Schätzungen oder Hellsehen basieren, für Metriken zu verwenden?

Ja! Messungen sind notwendig.

Warum ist das User Story schätzen wichtig?

Damit,

• der Scrum Master auf Basis der Entwicklungsgeschwindigkeit (Velocity) Engpässe identifizieren kann,
• der Product Owner Releases planen kann,
• das Dev-Team die personelle Kapazität für den Sprint planen kann.

Wichtig: Keinesfalls darf man agil unerfahrenen Stakeholdern die Messung der Performance von Teams, über die Menge der erledigten geschätzten 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 die Komplexität von User Storys 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 in 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, auf wie viele Story-Points denn nun diese und jene User-Story geschätzt werden muss. Außerdem kennen sich die Tester und die Designer mit der Produktion gar nicht aus. Deshalb können nur Entwickler User Storys “richtig” bewerten und schätzen.

So zumindest die landläufige Meinung.

Interessant ist: Story Points weisen keine Einheit auf. Story Points sind ohne Skala. 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 User Story Points zueinander.

Hier findest du einen Artikel über die Definition von User Storys.

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 User Storys 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-Storys. 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 Storys 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-Storys 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-Storys in 60 Minuten schätzen.

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