User Storys schÀtzen ist einfach

7 geheime User Story Tipps

Sofort umsetzbar

7 Tipps fĂŒr bessere User Storys

Abonniere meine tĂ€glichen Agile-Insider Tipps und ich schenke dir mein E-Book „User Story Secrets“. Trage dich jetzt mit deiner E-Mail-Adresse ein:

Du wirst damit Teil meiner exklusiven E-Mail Liste. Abmeldung jederzeit möglich.

User Storys schÀtzen

Inhalt

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.

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.