Agiles Schätzen lohnt nicht?

2017-10-07T09:48:40+00:00
4 Minuten Lesedauer

TL;DR

Schätzen ist zwar nur eine von vielen Möglichkeiten, offene Fragen von Arbeitspakten zu identifizieren, sollte aber als Werkzeug in keinem Koffer fehlen.

Schwarz, Weiß … oder doch vielleicht Grau?

Es ist doch alles so einfach.

Aufgaben werden in einem kontrolliertem und stabilen Prozess definiert und dann abgearbeitet. Vergessene Themen werden geklärt, wenn sie auftauchen. Sogar eingepackt in agile Vorgehensweisen erlebe ich immer wieder, dass sich Teams und Produkt-/ und Projektverantwortliche unzufrieden mit der Team-Leistung zeigen.

Das Problem damit wird von sehr vielen sehr schnell und richtig identifiziert.

Unklarheiten müssen vorab geklärt werden.

Das, verbunden mit einem Meeting in dem alle Beteiligten anwesend sind, wird zur Problemlösung herangezogen. Gängiges Vorgehen mit agilen Methoden ist dann das (agile) Schätzen, welches die subjektive Einordnung der einzelnen Teammitglieder zur jeweiligen Aufgabe abfragt. Ohne auf das genaue Vorgehen einzugehen, wird davon ausgegangen, dass sich Fragen von Team-Mitgliedern in den Ergebnissen der Schätzung widerspiegeln:

  • Als Teammitglied kann ich nur schätzen, wenn ich ausreichend viel über die vorliegende Aufgabe weiß. Dazu gehört nicht nur die konkrete Ausprägung, sonder auch Grenzsituationen oder ganz bewußt auch weiße Flecken die es zu erkunden gilt.
  • Als Team kann ich auf die Schwarmintelligenz zurückgreifen. Bestimmt wird Sascha das Thema anders betrachten als Jan. Sollten sie dabei zu unterschiedlichen Ergebnissen kommen, zeigt sich das wahrscheinlich in der Schätzung. Eine Situation, auf der man ganz hervorragend aufbauen kann.

Schätzungen decken offene Fragen auf und lösen Unklarheiten.

In den ersten Schätzrunden mit darin unerfahrenen Teams habe ich durchweg positive Erfahrungen gemacht. Da das sehr gut klappt und von den meisten auch so wahrgenommen wird, wird diese Technik intensiv genutzt. Mit dem Ergebnis, dass ein wahrer „Schätzmarathon“ zu bewältigen ist, in dem Aufgaben bis ins kleinste Detail besprochen werden. So habe ich schon viele Schätzrunde mitgemacht, in denen sich zwei bis drei Personen über ein Thema unterhalten haben, während der Rest von fünf bis sieben Personen anderen Dingen nachging, da sie einfach nicht mitdiskutieren konnten. Ich denke, dass das zu dem natürlichen Lernprozess dazugehört und völlig normal ist, sofern man die Sackgasse erkennt:

Schätzungen zur Klärung aller Fragen bis ins letzte Detail sind nicht sinnvoll.

Damit reiht sich das Meeting zur Schätzung von Aufgaben in die lange Reihe an Pflichten ein, die nicht wertschöpfend sind und mit wenig Begeisterung von allen Beteiligten erledigt wird. Halt ein ganz normales Meeting …

Schätzungen sollten nur so viel wie notwendig, nicht so viel wie möglich genutzt werden.

Etwas abstrakt, aber zur Lösung kann man zum Beispiel recht einfach eine Dreiteilung der Arbeit vornehmen:

  1. Ideen – Themen im Projektkontext, die egal wem, egal wann und egal mit welcher Wichtigkeit jemandem eingefallen sind. Also unser Ideenspeicher.
  2. Anforderungen – Ideen oder gesetzte Themen, welche in das Produkt einfließen sollen, aber noch nicht vollständig spezifiziert sind und in ihrem Reifegrad erhöht werden müssen.
  3. Aufgaben – Entstehen aus den Anforderungen, sobald diese in ihrem Reifegrad so weit gebracht wurden, dass sie von den Team-Mitgliedern eingeschätzt werden können.

Als weiteren Schritt sollte auch die Schätzrunde selbst in diese Blöcke gegliedert werden.

  1. Gibt es neue, beachtenswerte Ideen die wir zu den Anforderungen nehmen sollten?
  2. Welche fachlichen und technischen Risiken sehen wir bei den vorhandenen Anforderungen? Sind diese gefährdet für die weitere Produktentwicklung? Sind diese vorab zu klären? Wenn ja, wer erledigt das bis zur nächsten Schätzrunde?
  3. Sind die vorhandene Anforderungen verstanden, können geschätzt werden und zur Umsetzung freigegeben werden?

Teilnehmer sind alle Personen, die etwas zur Definition der Arbeit beitragen können. Neben dem Team und dem Produktverantwortlichem ist es immer empfehlenswert, wenn die eigentlichen Anforderungs-/ Ideenerzeuger dabei sind. Klar, es geht nichts über direkte Kommunikation, wenn es der Projektrahmen zu lässt.

Als Dauer rechne ich hier mit ca. 30 Minuten für den kompletten Ablauf. Bis sich das Vorgehen im Team gesetzt hat, kann man auf 45 Minuten gehen. Sollte das nicht ausreichen, würde ich erst versuchen die Häufigkeit zu steigern – im Umkehrschluss übrigens auch verringern – bevor ich das Meeting in seiner Dauer ausweite. Irgendwann macht selbst das Schätzen und dadrüber Diskutieren keinen Spaß mehr …

Als Gesamtbild ergibt sich dann folgendes:

Pragtics - Reifeprozess von Aufgaben