Hallo Leute,

Scrum ist auch ein Prozess des Lernens und Verbesserns. In der Tat funktioniert das Lernen am besten, wenn man es selber erlebt und nicht, wenn andere sagen, dass man dies oder das nicht machen sollte. Falls ihr Kinder und einen heißen Herd habt, wisst ihr, was ich meine („Fass es nicht an, es ist heiß! Ehrlich!... *pfshhh*”), aber ich schweife vom Thema ab. Also das Team muss Dinge erleben, um zu lernen, sich zu verbessern und schneller und besser zu werden. Hier erfahrt ihr, warum der letzte Sprint nicht wie geplant verlief und was man dagegen tun kann.

Lange Storys sind wegen mehreren Gründen problematisch.

Erstens sind sie schwierig abzuschätzen. Lange Storys umfassen mehr Arbeit und Aufgaben, so dass es einfach schwieriger ist, sie in Gedanken zusammenzufassen und zu quantifizieren.

Zweitens wächst die Fehlerspanne mit der Größe der Story. Lasst uns annehmen, dass wir mit 30% Genauigkeit schätzen. Das bedeutet, dass die Standardabweichung für eine Story, die drei Punkte wert ist, ungefähr eins beträgt. Die Standardabweichung für eine 40-Punkte Story beträgt also zwölf. Das bedeutet nun nicht, dass die Schätzung weniger genau ist, aber die Effekte sind viel größer. Auf lange Sicht hin gleichen sich die Schätzfehler wieder aus. Ein paar Storys werden überschätzt, andere wiederum unterschätzt. Am Ende eines Sprints heben sich diese auf und man endet da, wo man anfangs auch geplant hat zu enden. Das funktioniert besonders gut, wenn alle Storys in etwa dieselbe Größe haben. Wenn eine große Story im Sprint ist, deren Schätzwert nahe an den Grenzen des Fehlerintervalls liegt, bedarf es einer Vielzahl an kleineren Storys auf der anderen Seite des Fehlerintervalls, die das Ganze wiederum ausgleichen. Das wird meistens nicht geschehen, also ist die Planung des Sprints schiefgelaufen. Keine gute Sache. Das ist aber genau das, was im letzten Sprint passiert ist.

Drittens verliert man den Überblick über den Gesamtfortschritt. Bei Scrum werden die Punkte der abgeschlossenen Storys in einem Burndown-Chart verfolgt. Ja, man kann noch einige andere Dinge verfolgen, aber das ist das Wichtigste. Das Verfolgen auf Task-Ebene ist auch keine gute Idee. Ich werde eine seperaten Eintrag verfassen, falls die Gründe interessieren. Also, wenn eine Story abgeschlossen ist, vergleicht man die verbleibenden Punkte mit der Menge an Punkten, die zu diesem Zeitpunkt des Sprints noch offen sein sollten. Dann weiß man, ob man gut in der Zeit liegt oder schneller oder langsamer als geplant ist. Wenn die Story sehr groß ist, vergehen viele Tage, bevor sie beendet ist und man die verbleibenden Punkte vergleichen kann. Während dieser Zeit weiß man kaum, ob man gut in der Zeit liegt oder in die eine oder andere Richtung abrutscht.

Also was machen wir mit langen Storys? Einfach. Wir teilen sie in mehrere kleine auf. Zum Beispiel anstelle von einer Story für das Importieren, Einlesen, Speichern und Anzeigen von Hand-Histories, teilen wir diese in kleinere auf, so dass das Einlesen der Daten eine Story ist. Eine andere bezieht sich auf das Speichern der Daten in der Datenbank und eine weitere kümmert sich um das Anzeigen der Ergebnisse aus der Datenbank.

Das war ein kleiner Ausflug zu Scrum, dem Entwicklungsprozess und wie wir diesen handhaben. Lasst mich wissen, ob ihr das interessant findet und mehr über solche Themen erfahren wollt.

Cheers,
M.