Agiles Schätzen: Wie man die richtigen Schätz-Kategorien findet (ein möglicher Weg)

Beim Untersuchen der Schätzgüte seines Teams hatte einer unserer Entwickler, David Führ, eine hochinteressante Idee. Anstatt die Kategorien – bei Schätzpokerkarten z.B. meist 1, 2, 3, 5, 8, 13, 20 – fest vorzugeben und die Backlog-Items im Schätzprozess entsprechend zu kategorisieren, könnte man auch datengetrieben vorgehen. Und zwar indem man die tatsächlich gebrauchte Arbeitszeit für schon bearbeitet Tickets untersucht, ob sich da vielleicht versteckte Kategorien (Gruppen, Cluster, Klumpen) finden.

Eine einfache Veranschaulichung: Wir haben fiktive 25 Tickets auf einer Geraden angeordnet nach Bearbeitungszeit. Man sieht in der ersten Grafik.

 

Dummerweise ist die Wirklichkeit nicht ganz so eindeutig. Eine realistische Grafik sähe wohl eher so aus:

 

 

Und da ist es schon viel schwieriger, die Gruppierungen, i.e. Cluster, zu erkennen. Hier kommt uns die Statistik zu Hilfe. Das Verfahren, das wir brauchen, nennt sich Clusteranalyse. Sie wird uns zeigen, ob es statistisch auffällige Gruppen in unseren Daten gibt, also Gruppen von Tickets, die bzgl. der Bearbeitungszeit irgendwie zusammengehören.

Mit dem Statistkprogramm R rechnen wir im Folgenden eine solche univariate Clusteranalyse über reale Daten aus einem unserer Projekte. Wir untersuchen 315 Tickets, die bearbeitet wurden. Das Histogramm, also die Verteilung der Tickets nach Bearbeitungszeit, sieht so aus:

 

 

Wir sehen in der Grafik, dass die meisten Tickets 2h Bearbeitungszeit (Touch Time) brauchen, im Schnitt braucht ein Ticket 11h bis es fertig ist (der Median liegt bei 6.25) und 90% der Tickets brauchen weniger als 22h.

Gibt es nun in diesen Bearbeitungszeiten statistisch auffällige, für unser Auge aber verborgene Kategorien? So wie oben im Beispiel kleine vs. große Tickets, nur halt vielleicht etwas differenzierter? Das ist mit R einfach herauszufinden.

So definieren wir das Datenset in R (das ist eine Liste der Bearbeitungszeit jedes einzelnen Tickets in Stunden):

x=c(5.25,1.25,7.5,9,1,3,2.5,2.5,13.75,8.5,9,16.75,3.75,4,13,1.75,1
0,9.5,0.5,2.75,17.25,0.25,21,1.5,2.25,29,30.25,47.5,18.75,0.5,1.25
,36.5,6.75,7,4,0.75,11.5,4.5,1.25,1,3.5,8.25,9.5,3.25,10.5,9.75,4.
75,1.75,2.25,0.25,6.75,12,3.25,19.5,5.25,19,1.75,2.25,39.5,2.5,4.7
5,1.75,9.25,1.25,4.75,1.5,2,6.5,3,2.75,5.5,2,14,3.75,1.5,7.25,21.2
5,3,4.25,15,11.5,4.5,37.75,18.5,0.75,0.25,1.25,1.75,0.75,0.5,1.5,1
1.5,0.75,2.5,4.75,3,1.5,1.5,0.25,3.75,2.75,5,1.5,2.25,0.75,3,11.75
,1.75,0.5,11,7,1,1.25,6.25,3.75,16.75,8,5.75,8.75,9.25,6.25,11,3.5
,1.5,7.5,0.25,0.75,3,4.25,6,0.25,3.75,16.75,10.25,15.75,21.25,0.5,
2.5,1.25,16.5,5,1.75,2.5,7.5,4.5,10.5,2.25,4,3.5,3.25,2.25,2.5,17.
25,27.75,4.5,1.25,6,9.75,1,4.5,9.5,0.75,11.75,13,20.25,8.25,5,9.25
,12.5,3.25,11,9.25,6.75,33.5,8,28.5,18.25,10,2.75,1.75,0.5,0.5,2,2
.5,1.5,2.5,6.25,0.75,0.75,24.25,23.25,0.75,7.25,17,6.25,0.5,8.25,9
,1.25,1,1.25,6.75,3.5,1.5,3.75,0.5,18.75,1,16.75,10.25,26.75,9,2.7
5,18.5,8.75,13,11.25,22,5.5,7.25,4.75,21.5,12.75,19.5,31.5,9.5,0.5
,2,8.5,1.75,1.5,4.25,19.75,8.75,11.5,14.75,11.75,2.25,3,2,6.25,7.5
,2.5,14.5,7.75,4.5,3.75,5,4,1.25,22.25,16.25,8.5,1.25,10.25,0.5,79
.5,0.75,18.25,3.6,5.25,18.25,24.5,19,28,23.75,20.25,18.75,14.25,3.
25,15.75,2)

So rechnen wir die Clusteranalyse:

result <- Ckmeans.1d.dp(x)

So visualisieren wir das Resultat:

plot(x, col=result$cluster, pch=result$cluster, cex=1.5,
main="Optimal univariate clustering with k estimated",
sub=paste("Number of clusters is estimated to be", k))
abline(h=result$centers, col=1:k, lty="dashed", lwd=2)

 

 

Wir sehen farblich markiert die 5 Cluster, die R in unseren Daten gefunden hat. Es sind Tickets mit um die 2h Bearbeitungszeit (das sind die meisten), solche mit um die knapp 10h Bearbeitungszeit, dann solche, die um die knapp 20 Stunden brauchen und solche mit gut 30h Bearbeitungszeit. Das eine Ticket mit den knapp 80h sollten wir klar als Ausreißer einordnen, analysieren, wie es dazu kommen konnte, wir machen aber keinen eigene Kategorie für solche Tickets.

Jetzt orientieren wir uns an den Durschnittswerten der ersten vier Cluster, um unsere Schätzkategorien festzulegen. Die genauen Durchschnitte erhalten wir so (man kann sie in der Grafik oben nur ungefähr sehen):

result$centers
[1] 2.384247 9.173611 18.670732 33.041667 79.500000

Man könnte nun also den Schätzprozess so festlegen: Das Team beurteilt beim Schätzen, ob ein Ticket Small, Median, Large oder X-large ist.

  • Small = gute 2 h
  • Medium = gute 9 h
  • Large = gute 18 h
  • X-Large = gute 30 h (bzw. halt deutlich größer als Large)

Auffällig ist, dass der bloße Augenschein (zumindest bei mir, dem Autor;) nicht zu den 4 Clustern führen würde: Ich hätte „nach Gefühl“ eher eingeteilt in Tickets bis knapp 10h, Tickets bis knapp 25h und die drüber (den Ausreißer hätte ich natürlich auch extra eingeteilt).

 

 

Interessant ist auch, dass die den Daten zugrundeliegenden Cluster nicht der üblichen Story-Point-Fibonacci-Reihe folgen, sich also nicht auf 1,2,3,5,8,13,20 mappen lassen. Das heißt, dass zumindest für unsere Daten die Fibonacci-Reihe keine gute Kategorisierung ist, also keine guten „Töpfchen-Größen“ hergibt.

Autor

Agile Transformation heißt ständige Erneuerung.

Sprechen Sie mit uns über Ihren Weg in die digitale Zukunft, wir freuen uns drauf!

Autor

Sacha StorzAgile Coach