In der agilen Softwareentwicklung erfreut sich das relative Schätzen von Anforderungen mit Story Points, neben der klassischen Zeitschätzung, großer Beliebtheit.

Doch wie kommt man dort hin? Welche Schätzmethode passt ins Team und liefert gute Ergebnisse?

Ich möchte drei Arten vorstellen, wie sich Anforderungen komfortabel schätzen lassen. Jede Methode hat dabei ganz eigene Vorzüge – welche am besten passt lässt sich aber wohl fast nur durch Ausprobieren herausfinden. Für die folgenden Beispiele gehe ich davon aus, dass Software Anforderungen als User Stories formuliert und in Story Points gemessen werden:

Team Estimation Game

Diese Methode eignet sich ganz hervorragend für Teams, die noch keine Erfahrung mit Story Points haben! Durch sie lässt sich auch für (fast) jedes Story Point Level Referenz-User Stories festlegen. Sven Röpstorff hat dazu zwei fantastische Artikel geschrieben (Team Estimation Game | Bye bye, Planning Poker?).

Beim Team Estimation Game wird wie folgt vorgegangen:

Vorbereitung

• Alle User Stories liegen einzeln ausgedruckt vor
• Das Scrum Team ist komplett vertreten und auch der Product Owner ist anwesend

Regeln

• Jemand aus dem Entwicklerteam nimmt sich die oberste Story, liest sie laut vor und hängt sie an die Wand.
• Der nächste aus dem Entwicklerteam nimmt die nächste Story, liest sie laut vor und hängt sie ebenfalls an die Wand. Er hat drei Möglichkeiten:
  • Die Story ist (seiner Meinung nach) ähnlich groß wie die Erste. Dann hängt er sie neben die bereits an der Wand hängende Story,
  • Die Story ist weniger groß als die bereits hängende – die neue Story wird unter die bereits an der Wand hängenden gehängt,
  • Die Story ist größer als die bereits hängende – die neue Story wird über die bereits an der Wand hängenden gehängt,

  verbunden mit einer kurzen Erklärung, ohne Diskussion.

• Ab der dritten Story Card gibt es die folgenden Optionen:
  • Ausspielen der obersten Story wie oben beschrieben.
  • Umhängen einer bereits hängenden Karte, wieder verbunden mit einer kurzen Erklärung, ohne Diskussion.
  • Aussetzen.

Das Spiel ist beendet, wenn keine Stories mehr auf dem Tisch liegen und alle Spieler aussetzen.

Wichtig ist während dem Spiel, dass die Entwickler die Stories wirklich nur miteinander vergleichen und sie nur darauf basierend an der Wand anordnen. Es ist nicht wichtig wie viel größer User Story X als User Story Y ist, sondern nur, dass sie größer ist und ein Level höher hängt. Die zunehmende Abstände der vereinfachten Fibnocci-Reihe übernehmen dann die Größenrepräsentation.

Idealerweise hängen die Story Cards nach dem Spiel auf sieben oder acht Größenleveln – so bleibt nach oben und nach unten noch etwas Spielraum für zukünftige Schätzmeetings. Nun kann der Scrum Master die Level mit Story Point Werten versehen und als Ergebnis hat das Team repräsentative Referenzstories und in Story Points geschätzte Anforderungen, ohne jemals vorher damit gearbeitet zu haben!

Die Methode ist natürlich nicht nur für Initialschätzungen geeignet, sondern kann auch über einen längeren Zeitraum verwendet werden. Dann werden die zu schätzenden Anforderungen eben mit den bereits vorhandenen verglichen und den Story Point Werten zugeordnet.

Nachteil des Team Estimation Games ist aber wohl die fehlende Diskussion der Schätzgegenstände. Zwar werden beim Umhängen einer Karte Argumente genannt, und jeder Entwickler kann wieder umhängen und erklären, das ist jedoch sehr umständlich und zeitraubend. Wenn viele User Stories geschätzt werden sollen und sich die Entwickler uneins sind kann es daher schnell zur Frustration des Product Owners führen. Aber dafür gibt es ja auch noch andere Schätzmethoden…

Planning Poker

Dies ist wohl die bei weitem populärste Methode um die Größe einer User Story festzulegen:

Der Product Owner (oder Product Manager) stellt eine User Story vor, die Entwickler diskutieren sie kurz, fragen eventuell nach, und entscheiden sich für einen Wert der vereinfachten Fibonacci-Folge. Sollte es zu großen Unterschieden in der Abschätzung kommen, erklären sich die Entwickler, die am weitesten auseinander liegen und es wird neu geschätzt.

Vorteil gegenüber dem erwähnten Team Estimation Game ist in jedem Fall die Kommunikation zwischen den Entwicklern bevor geschätzt wird, jedoch sollten sich die Entwickler schon eine Ahnung haben wie “groß” ein Story Point ist um Anforderungen korrekt abschätzen zu können.

Das dritte