Poker

Abschätzungs-Meetings

Abschätzungen sind unbeliebt, für eine solide Planung aber unerlässlich. In diesem Artikel stelle ich Dir zwei Methoden zur effizienten Durchführung von Abschätzungs-Meetings vor. Damit sparst Du nicht nur eine Menge Zeit und Nerven, sondern kommst auch zu soliden und vom Team akzeptierten Abschätzungen.

Die Grundidee der hier vorgestellten Methoden besteht zum einen darin, dass das gesamte Team eingebunden und der Wert somit verlässlicher und allgemein akzeptiert wird und dass eine große Anzahl von Anforderungen im Rahmen eines Meetings abgeschätzt und somit möglichst wenig Zeit vergeudet wird.

Im Folgenden gehe ich davon aus, dass Du zur Abschätzung Story-Points verwendest. Letztlich kannst Du mit den vorgestellten Methoden aber auch Abschätzungen in anderen Einheiten, wie zum Beispiel den klassischen Personentagen, durchführen.

Voraussetzungen

Die notwendigen Voraussetzungen hängen davon ab, was Du erreichen möchtest beziehungsweise in welchem Projektstadium Du Dich befindest.

Zu Beginn eines neuen Projektes möchtest Du Dir wahrscheinlich erstmal einen Überblick über die anstehenden Aufwände verschaffen oder Du musst sogar erstmal ein Estimation-Kick-Off durchführen um Eure Punkte-Skala zu normieren. In diesen Fällen genügt es, wenn Deine Anforderungen nur auf grober Ebene existieren – zum Beispiel in Form von User-Story-Titeln. Informiere Dein Team zu Beginn des Abschätzungs-Meetings, dass es nur um eine grobe Abschätzung geht und die Stories zu einem späteren Zeitpunkt nochmal genauer abgeschätzt werden.

In einer späteren Phase – spätestens bevor Stories ins Planungs-Meeting eingereicht werden sollen – müssen sie detailliert abgeschätzt werden. In diesem Fall müssen die zu schätzenden Stories bereits im Rahmen von Backlog-Groomings vollständig besprochen worden sein und befinden sich somit im Status »abgestimmt«.

Termin

Abschätzungen sind in Scrum ein kontinuierlicher Prozess. Neben einer eventuellen initialen Grobabschätzung zur Erstellung einer Planung, werden Abschätzungs-Meetings nach Bedarf durchgeführt. Du solltest Stories nicht einzeln abschätzen lassen, sondern stets eine Sammlung von mindestens zehn Stories in ein Abschätzungs-Meeting einreichen – nur so wird der Vorgang effizient.

Das Abschätzungs-Meeting sollte möglichst zeitnah nach dem Backlog-Grooming stattfinden, im Rahmen dessen die Stories besprochen wurden. So sind die Erinnerungen an das Besprochene noch frisch und ihr erspart Euch viele Diskussionen. Auf der anderen Seite sollten die Stories auch in einem absehbaren Zeitraum (optimaler Weise nicht mehr als zwei Monate nach der Abschätzung) umgesetzt werden – ebenfalls damit die Erinnerungen noch halbwegs frisch sind.

Teilnehmer

Im Abschätzungs-Meeting sind alle Scrum-Rollen involviert: Der Scrum-Master moderiert das Meeting, der Product-Owner muss zur Klärung von Details zur Verfügung stehen und das Team führt die Abschätzung durch.

Varianten

Es existieren diverse Varianten zur Durchführung von Abschätzungs-Meetings. Ich stelle Dir im Folgenden zwei Varianten vor, die ich selbst regelmäßig anwende und mit denen ich gute Erfahrungen gemacht habe. Beide haben ihre Vor- und Nachteile. Mein Team kennt beide Varianten und ich lasse sie vor dem Abschätzungs-Meeting entscheiden, welche sie anwenden möchten.

Planning-Poker

Planning-Poker (oder »Abschätzungs-Poker«) ist die populärste Methode zur Durchführung von Abschätzungen im agilen Umfeld. Und das aus gutem Grund: Es hilft dabei unterschiedliche Vorstellungen bezüglich der Komplexität einer Story innerhalb des Teams aufzudecken und somit Missverständnisse auszuräumen und trotzdem zügig zu akzeptierten Abschätzungen zu gelangen.


Jedes Team-Mitglied erhält ein Kartendeck bestehend aus Karten, die Eure Story-Point-Skala abbilden, also üblicherweise je eine Karte für die Punktewerte 1, 2, 3, 5, 8, 13, 20, 40 und 100.

Der Product-Owner stellt nun die erste Story vor – gegebenenfalls auftretende Fragen werden umgehend geklärt. Liegen keine Fragen mehr vor wählt jedes Team-Mitglied die Karte, dessen Wert seiner Meinung nach am besten passt und legt sie verdeckt auf den Tisch. Wurde die letzte Karte ausgelegt drehen alle ihre Karten um.

Im Idealfall haben alle Mitglieder die gleiche Karte gewählt – meist wird es aber eine Abweichung geben. Beträgt die Abweichung lediglich fünf oder weniger Punkte (also zum Beispiel 5 und 8) und ist relativ gleichmäßig verteilt lohnt sich meiner Erfahrung nach eine Diskussion meist nicht – wählt einfach den höheren Wert als Abschätzung für die Story.

Gehen die Abweichungen weiter auseinander sollte der Scrum-Master die Diskussion initiieren, zum Beispiel in dem er jemanden, der den höchsten und jemanden der den niedrigsten Wert gelegt hat nach seinen/ihren Beweggründen befragt. Dadurch werden unterschiedliche Vorstellungen bezüglich der Umsetzung aufgedeckt und können geklärt werden. Hier ist Geschick seitens des Scrum-Masters gefragt, um die Diskussionen nicht ausarten zu lassen, aber auch nicht zu früh »abzuwürgen«. Ist das Team bereit kann eine weitere Abschätzungsrunde durchgeführt werden, die nun wahrscheinlich zu einem einheitlicheren Ergebnis führt.

Je nach Diskussionsbedarf könnt ihr mit dem Planning-Poker 10 bis 15 Stories pro Stunde abschätzen.

Abschätzungsspiel

Die Stärke des Abschätzungsspiels liegt in seiner Geschwindigkeit: Mit dieser Methode könnt Ihr 30 bis 50 Stories pro Stunde abschätzen. Damit eignet sich die Methode besonders gut für eine initiale Grobabschätzung. Da immer nur ein Team-Mitglied aktiv ist regt diese Methode nicht so stark die Diskussion an, wie das beim Planning-Poker der Fall ist. Es besteht die Gefahr, dass die Team-Mitglieder, die gerade nicht an der Reihe sind eher abschalten.

Zur Durchführung müssen alle abzuschätzenden Stories in Papierform vorliegen. Sie werden als Stapel auf einen Tisch gelegt. Ihr benötigt ein großes Whiteboard, das ihr in Spalten unterteilt, die den Werten Eurer Story-Point-Skala entsprechen – also je eine Spalte für die Werte 1, 2, 3, 5, 8, 13, 20, 40 und 100.

Vor dem Termin hat das Team die Aufgabe Referenz-Stories für die verschiedenen Werte auszuwählen – diese werden dann zu Beginn des Meetings in der obersten Zeile in den jeweiligen Spalten aufgehängt. Sie dienen dem Team als Orientierung um die Komplexität der abzuschätzenden Stories mit der bereits abgeschätzter Stories vergleichen zu können.

Nun beginnt das Spiel: Das Team-Mitglied, das als erstes an der Reihe ist, nimmt sich die oberste Story vom Stapel und liest sie vor. Danach hängt es die Story ans Whiteboard in die Spalte, deren Punktewert es für angemessen hält. Nun ist das nächste Team-Mitglied an der Reihe und hat zwei Möglichkeiten:

  1. Eine neue Story vom Stapel nehmen, sie vorlesen und in eine Spalte hängen.
  2. Oder: Eine bereits hängende Story in eine andere Spalte verschieben.

So geht es reihum, bis alle Stories vom Stapel bearbeitet wurden (oder die Zeit abgelaufen ist). Dann bekommt reihum jeder nochmal die Möglichkeit eine Story umzuhängen.

Das häufige Umhängen einer Story zeigt, dass das Team unterschiedliche Vorstellungen von deren Komplexität hat. Ihr solltet sie daher bei jedem Verschieben mit einem Klebepunkt oder Strich markieren. Möchte ein Team-Mitglied eine Story ein drittes Mal umhängen solltet ihr sie aus dem Spiel nehmen und am Ende durchsprechen, um sie dann gemeinsam einem Punktewert zuzuordnen.

Fazit

Egal für welche Abschätzungsmethode Du Dich entscheidest: Durch die Einbeziehung des gesamten Teams und den klar geregelten Ablauf kommst Du schnell zu Abschätzungen, die vom gesamten Team akzeptiert sind.

Das Abschätzungsspiel hilft bei der zügigen Abschätzung vieler Stories – dafür werden nicht alle Team-Mitglieder so eng eingebunden wie beim Planning-Poker, das Diskussionen stärker anregt, aber mehr Zeit beansprucht. Gerade zum initialen Abschätzen vieler Stories auf einem abstrakten Level ist das Abschätzungsspiel eine gute Alternative.

Haben sich bei Dir noch weitere Methoden in der Praxis bewährt?

Tags:, , ,

Trackback von deiner Website.

Sven Wiegand

Ich leite seit 2005 Softwareprojekte und führe Entwicklungsteams in mittelständischen Softwareunternehmen. Nach einigen erfolglosen Projekten auf Basis des konventionellen Wasserfallmodells begann ich 2008, Scrum anzuwenden. Seitdem stellte ich mehrere Teams erfolgreich auf agile Methoden um. Auf »Agil Managen« möchte ich meine Erfahrungen aus der Praxis mit Dir teilen.

Kommentieren