Es kommt mir manchmal so vor, als gäbe es zum Thema Scrum mindestens so viel Unwissenheit, falsches Wissen und missverstandene Praktiken wie zum Thema Sex. Als wir pubertierende Teenager waren, wussten natürlich alle wie es geht. Echte Erfahrung hatten viele von uns damals auch nicht. In der Bravo gabe es eine Kolumne, in der ein “Arzt” versuchte aufzuklären und die Ängste abzubauen.
Ich möchte gerne eine ähnliche Kolumne starten: Dr. Scrum antwortet. Namensähnlichkeiten sind dabei natürlich rein zufällig :)
Die Idee dieser Kolumne ist es, Eure Fragen über Scrum zu beantworten, mit dem Halbwissen aufzuräumen und die Ängste derjenigen, die sich an Scrum heranwagen, abzubauen.
Dazu benötige ich natürlich eure Fragen. Ihr schickt diese Fragen bitte an: DrScrum@borisgloger.com.
Die erste Frage, kommt von einem ScrumMaster in Hamburg:
Bei uns ist ein Problem beim Schätzen von Stories aufgetaucht: wie behandelt man (inhaltliche) Komplexität vs. „Fleißarbeit”?
Wir schätzen in den Estimation Meetings ja SIZE im Sinne von Komplexität ab. Die Grundidee ist ja, hier zu schätzen, wie schwierig ein Backlog Item ist. Jetzt gibt es aber Sachen, die sind zwar nicht sooooo schwierig, dauern aber elendig lange, weil man z.B. jede einzelne Seite anfassen und refakturieren muss. Damit geht natürlich die gemessene Velocity massiv in den Keller, weil das ganze Team ja nur an so einfachen Dingen arbeitet? Hast Du Ideen dazu?
Dr. Scrum: Der grundlegende gedankliche Fehler in deiner Schilderung ist, dass die Size so etwas wie die Komplexität ist. Das war damals als die XP Community mit dieser neuen Schätzmethode angefangen hat, eine gute Idee. Sie hat aber leider in die Irre geführt. Denn sie erzeugt das oben beschriebene Problem. Wie schwer ist eine Story. Wieder ist man beim Schätzen von Aufwänden anstatt die Größe eines Backlog Items zu schätzen. Ein Backlog Item ist nicht schwer, es ist GROSS.
Wir schätzen die relative Andersartigkeit einer Funktionalität zu einer anderen ein. Da geht es nicht um Schwierigkeit oder Dauer, oder gar Aufwände.
Die Schwierigkeit, also die Art und Weise der Implementierung, drückt sich in dieser Schätzmethode in der Velocity aus. Ist diese langsam, dann hat das Team wohl eine schwierige oder lange dauernde Arbeit getan, um dieses “so-große” Feature zu liefern.
Die Velocity ist ein Resultat! Daher werden die Schätzungen auch nach drei Sprints genau. Die Velocity wird gemessen, sie kann geschätzt werden, aber am Ende ist sie das Resultat einer durchgeführten Messung.
Fehlerhaft kann bei dieser Methode, wenn sie richtig durchgeführt wird, einzig die Einschätzung der Relation der Backlog Item zueinander sein.