Seit ich das Buch Agile Estimating and Planning von Mike Cohn gelesen habe, ist es eine große Hilfe bei der Durchführung agiler Projekte. Eine der Ideen, die ich sehr mag, ist die Schätzung von User Stories in einem Product Backlog in einem abstrakten Maß: Story Points. Story Point-Schätzungen müssen nur relativ zueinander korrekt sein. Mit solchen Schätzungen können Sie die Geschwindigkeit überwachen, d.h. wie viel Last ist innerhalb einer Iteration realistisch? Folglich können Sie mit einem geschätzten Product Backlog einen Ausblick geben. Entscheidungen über Umfang, Zeitplan und Budget können auf sehr fundierte Weise getroffen und kontinuierlich verfeinert werden.
Die gängigste Methode zur Schätzung der User Stories in einem Product Backlog ist eine Planungspokersitzung. Meiner Erfahrung nach ist es jedoch ziemlich schwierig für ein Team, dies bei einer großen Liste von User Stories effektiv zu tun. Deshalb habe ich einen anderen Ansatz ausprobiert.
Meine Lernreise zur effektiven Einholung von Kostenvoranschlägen ohne Planungspoker
Wenn die Teammitglieder in einem Planungspoker eine große Liste von User Stories durchgehen, versuchen sie im Allgemeinen, so viele Details wie möglich über jede User Story herauszufinden. Für jede einzelne User Story trauen sich die Teammitglieder oft nicht, eine Schätzung abzugeben, wenn sie nicht über fundierte Kenntnisse verfügen. Aus diesem Grund liegt der Schwerpunkt zu sehr auf der Genauigkeit und nicht genug auf der Vollständigkeit. Solche Schätzungssitzungen erfordern viel Moderation, um in angemessener Zeit ein vollständig geschätztes Backlog zu erstellen. Außerdem ist es schwierig, beim Durchgehen der Liste sicherzustellen, dass die Schätzungen im Verhältnis zueinander korrekt sind. Dies erfordert einen wiederholten Vergleich von User Stories mit Stories, die bereits geschätzt wurden, während Sie die Liste durchgehen.
Pivotisierung des Schätzungsprozesses für mehr Geschwindigkeit und Vollständigkeit
Vor kurzem habe ich erfolgreich einen anderen Ansatz ausprobiert. Legen Sie jede User Story auf ein eigenes Blatt Papier und lassen Sie das Team sie auf einer horizontalen Skala anordnen. Dies geschah direkt nachdem der Product Owner einen Überblick über die User Stories gegeben hatte. Dieser Ansatz hat zwei Vorteile:
- Dadurch wird deutlicher, dass es bei der Schätzungssitzung um die Schätzung relativer Größen geht.
- Der Teamfokus ist mehr auf die gesamte Liste zur gleichen Zeit ausgerichtet.
Ich war erstaunt, wie schnell eine erste Reihenfolge festgelegt wurde. Währenddessen fanden einige der üblichen Diskussionen über die User Stories statt und es wurden einige User Stories aufgeteilt und gruppiert, aber viel mehr aus einem ganzheitlichen Blickwinkel als bei einem sequenziellen Ansatz. Um sicherzugehen, dass wir alle das Gefühl hatten, dass die Reihenfolge richtig war, gingen wir die User Stories nach einer ersten Einordnung immer noch der Reihe nach durch (von unten nach oben). Dies löste einige weitere Diskussionen aus und verbesserte die Reihenfolge, aber für die meisten Geschichten wurde schnell ein Konsens über ihren Platz auf der Skala erreicht.
Sobald die Reihenfolge stimmte, war die Zuweisung von Story Points zu den User Stories eine Sache des Ziehens von Linien zwischen Gruppen von User Stories auf der Skala. Danach wurden einige schnelle Triangulationen durchgeführt, um sicherzustellen, dass die Schätzungen der Story Points im Verhältnis zueinander korrekt waren. Im Vergleich zum Planungspoker besteht der Hauptnachteil dieses Ansatzes darin, dass er weniger dazu beiträgt, die unterschiedlichen Ansichten der Teammitglieder auszugleichen. Daher denke ich, dass dieser Ansatz in Situationen vorzuziehen ist, in denen es viele Storys zu schätzen gibt und/oder wenn die Teammitglieder keine Erfahrung mit der Schätzung relativer Größen haben.
Verfasst von
Marco Mulder
Unsere Ideen
Weitere Blogs
Contact