Agiles Schätzen

Planning Poker ist kein Game

Wer das erste Mal ein agiles Team beim Planning Poker (Schätz Poker) beobachtet, findet das Geschehen vielleicht überraschend. Das Vorgehen beim Schätzen ist im Grunde immer gleich:

Jedes Teammitglied hat ein Set an Zahlenkarten in der Hand. Das Team bespricht zunächst eine Anforderung, die typischerweise im User Story Format vorliegt. Dann überlegen alle Teammitglieder kurz, wie sie die Story einschätzen und ziehen zunächst verdeckt eine Karte aus ihrem Set. Alle Karten werden dann gleichzeitig aufgedeckt. Gibt es deutliche Abweichungen in den Schätzwerten, erklären die Teammitglieder mit dem höchsten und dem niedrigsten Wert kurz, was ihre Überlegungen zur Story sind. Dann wird das Schätzen wiederholt; in der Regel gleichen sich nach ein oder zwei weiteren Durchgängen die Schätzwerte an.

Was so spielerisch aussieht, ist aber durchaus kein Agile Game. Vielmehr ist das Planning Poker eine ganz bewährte Praktik, die viele agile Teams erfolgreich nutzen.

Der Erfolg des agilen Schätzens mit Planning Poker beruht vor allem auf fünf Elementen:

• Kommunikation:
  Der Product Owner erklärt und präzisiert Details der gewünschten Eigenschaften einer Anforderung. Die Teammitglieder stellen Fragen dazu und versuchen insbesondere zu verstehen, was mit der Umsetzung der Anforderung erreicht werden soll. Damit bauen alle ein gemeinsames tieferes Verständnis für die Anforderung, ihre Eigenschaften und den intendierten Kundennutzen auf. Für die Schätzung selbst nutzen wir die kollektive Team-Intelligenz; das allein schon bringt deutlich bessere Schätzwerte. Starke Abweichungen in den Schätzungen sind oft wertvolle Hinweise darauf, dass viele Aspekte noch unklar sind und das gemeinsame Verständnis im Team noch nicht ausreichend hergestellt ist.

• Komplexität statt Zeitaufwand:
  Statt einer Zeitdauer für die Umsetzung wie beim klassischen Schätzen nehmen wir beim agilen Schätzen die Komplexität einer Story in den Fokus. Damit bekommen wir ein abstraktes Schätzmaß, ähnlich wie es schon mit der Function-Point-Analyse bezweckt war. Häufig verwenden wir Story Points als Schätzmaß.

• Relative Schätzung mit Analogieverfahren:
  Jede Anforderung wird mit einer bereits bekannten Referenz-Story verglichen: ist die neue Anforderung in der Komplexität größer, gleich oder kleiner als die bereits bekannte Story. Verbunden mit dem abstrakten Schätzmaß bekommen wir damit schnellere und bessere Schätzergebnisse. Denn relative Größenvergleiche fallen Menschen deutlich einfacher als absolute Zeitschätzungen.

• Neutralität:
  Die Schätzwerte abstrahieren sowohl von den unterschiedlichen Kompetenzen und Vorerfahrungen einzelner Teammitglieder als auch von der Lernkurve, die das gesamte Team nimmt. Die Komplexität einer Story bleibt davon unberührt und die Schätzung muss nicht immer wieder neu überarbeitet werden.

• Empowerment und psychologische Sicherheit:
  In agilen Teams schätzen genau die Personen, die später auch die Arbeiten zur Umsetzung einer Anforderung selbst durchführen. Die Praktik des Planning Pokers stellt außerdem sicher, dass alle Teammitglieder beteiligt sind und ihre Argumente gehört werden, auch die der stilleren Mitglieder. Zum einen stärkt dieses gemeinsame Vorgehen das Erleben von Selbststeuerung, Selbstwirksamkeit und der eigenen Kompetenz. Das gesamte Team kann dann verlässlicher planen und leichter ein ehrliches Commitment abgeben.
  Wird Planning Poker als Praktik regelmäßig eingesetzt, ist dies geeignet psychologische Sicherheit innerhalb eines Teams und die gesamte Weiterentwicklung des Teams zu fördern. Voraussetzung dafür ist nach meiner Erfahrung, dass ein Scrum Master den Ablauf des Planning gut moderiert. Und dieser letzte Punkt ist in der Tat nicht zu unterschätzen, sondern ein echter Erfolgsfaktor für gutes Planning Poker und die Teamentwicklung.

Wie kommen wir nun von der agilen Schätzung zu einer zuverlässigen Releaseplanung des Produkts oder Projektplanung? Hierzu ermitteln wir die sogenannte Velocity eines Teams, das heißt die Anzahl der Story Points, die ein Team typischerweise pro Sprint wirklich in Form fertig gestellter User Stories schafft. Für die geplanten Anforderungen eines Releases können wir dann den Fertigstellungstermin extrapolieren. Und mit jedem weiteren Sprint wird diese Trendaussage besser.

Sie möchten Verfahren für agiles Schätzen und agiles Planen in Ihren Teams effizient nutzen? Oder wollen Sie allgemein die Teamentwicklung stärker fördern? Dann sprechen Sie mich an, ich kann Sie gut unterstützen.
Ihre Birgit Mallow