Warum User-Stories SchÀtzen?

User Stories schÀtzen, oder nicht?

User-Storys schĂ€tzen, 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.

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?”.

“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?

Ja! Messungen sind notwendig.

GrĂŒnde, warum User-Storys geschĂ€tzt werden

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.

Wichtig: Keinesfalls darf man agil unerfahrenen Stakeholdern die Performancebewertung der 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 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 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.

Ich wĂŒnsche dir eine stressfreie Zeit.
Frank

Frank Schatz

Frank Schatz

Als Trainer, Mentor und Coach ist Frank Schatz vielleicht einer der gefragtesten T-Shaped Agilisten im deutschsprachigen Raum. Er ist geprĂŒfter SachverstĂ€ndiger fĂŒr agiles Projektmanagement und seit ĂŒber 25 Jahren IT-Unternehmer, Agile Work Experte und Certified Instructor. Frank Schatz, damit es agil wird.

Agile Work

Die Agile Transformation

Agiles Mentoring