en
de

Risiken und Nebenwirkungen: Tracking Time Spent

24 Februar 2014
| |
Lesezeit: 3 Minutes

Im Scrum-Guide von 2011 stand auf Seite 14 noch drin: Scrum does not consider the time spent working on Sprint Backlog Items. The work remaining and date are the only variables of interest.

Die meisten Regeln haben Ausnahmen. Ich vermute, dass diese Regel darum in der Version vom Juli 2013 nicht mehr drin ist. Trotzdem gilt sie in den meisten Fällen, denn die Messung der aufgewendeten Zeit pro Sprint Backlog Item hat Nebenwirkungen.

Unnötiger (Zeit-)Aufwand

Um zu wissen, wieviel Zeit ich für welches Backlog Item aufgewendet habe, muss ich wissen, wann ich wie lange an was gearbeitet habe. Das klingt nach einem kleinen Aufwand, doch wieviel einfacher die Arbeit ohne diese Anforderung ist, merke ich jeweils erst wieder, wenn sie wegfällt und ich mich plötzlich ausschliesslich auf den Inhalt konzentrieren kann, statt nebenbei noch auf die Uhr zu schauen.

Offensichtlicher wird der Zusatzaufwand, wenn ich Dinge tu, die nicht zu einem geplanten Backlog Item gehören, wie zum Beispiel Schalttag-Bugs fixen. Dann geht nämlich die Diskussion los, auf welches Konto dieser Aufwand gebucht werden sollte. Wenn ich den Aufwand einem Backlog Item zuordne, dann verfälsche ich die Statistiken und die Verrechnung (und was sonst noch alles an diesen Zahlen hängt). Neben den Backlog Items habe ich jedoch keine grosse Auswahl von Töpfen, und egal wie viele es sind, von Zeit zu Zeit wird keiner so richtig passen.

Wenn wir schon bei der Verfälschung der Statistik sind: Nicht nur Dinge, die zu keinem Backlog Item gehören, verfälschen sie, sondern auch solche, die zu mehreren gehören. Dinge wie Refactorings, die nach der Umsetzung der ersten zwei Backlog Items zu einem Thema fällig werden, damit das dritte Backlog Item dann wieder einfacher wird. Zu welchem Backlog Item gehört der Aufwand für das Refactoring? Was, wenn unterschiedliche Sponsoren dahinter stehen?

Störungen im Feedback-Loop

Wenn ich für ein Backlog Item (oder einen Task) sowohl den Restaufwand als auch die bereits investierte Zeit regelmässig nachtragen muss, dann ist die Gefahr gross, dass ich eine Abkürzung nehme. Meistens ist diese Abkürzung, den Restaufwand nicht neu zu schätzen (was Denkarbeit ist), sondern ihn mit Hilfe der aufgewendeten Zeit zu berechnen (eine einfache Kopfrechnung). Damit wird der Restaufwand wertlos – unabhängig davon, wie oft die Teammitglieder einander gegenseitig erinnern, dass sie den Restaufwand schätzen und sich nicht von der aufgewendeten Zeit beeinflussen lassen sollten.

Eine weitere mögliche Nebenwirkung kann auftreten, wenn jemand die Schätzungen mit den aufgewendeten Zeiten vergleicht. Die Erkenntnisse aus dem Vergleich beeinflussen die nächsten Schätzungen. Je nachdem, wie geschätzt wird und was die Erkenntnis aus dem Vergleich war, treten verschiedene Effekte auf.

Als Beispiel ein Team, das mit Story Points schätzt: Sie schätzen aufgrund der erwarteten Kapazität des vorherigen Sprints, den umgesetzten Story Points und der erwarteten Kapazität des nächsten Sprints ab, wieviele Stories in den nächsten Sprint passen. Das ist für viele Teams eine gute Lösung. Eine weniger gute Idee ist, den Faktor Stunden pro Story Point über mehrere Sprints zu verfolgen und als Mass für die Entwicklungsgeschwindigkeit zu verwenden. Damit hat das Team ein Interesse, möglichst viele Story Points in einem Sprint zu erledigen. Das geht am einfachsten, wenn ein Story Point möglichst wenigen Stunden entspricht. Aber das widerspricht den relativen Schätzungen – der Idee hinter Story Points …

Fazit

Im Zusammenhang mit Code-Metriken hat mir ein erfahrener Architekt mal gesagt, dass wir die Zahlen doch liefern sollten, wenn sie einfach zu liefern sind und uns nicht weh tun. Je länger ich mit Scrum arbeite, desto mehr bin ich der Meinung, dass die aufgewendete Zeit pro Sprint Backlog Item meistens weder einfach zu liefern noch schmerzlos ist. Darum lohnt es sich, kritisch zu hinterfragen, wofür diese Zahlen denn benutzt werden, und ob die tatsächlich benötigten Informationen nicht aus bereits vorhandenen oder einfacher messbaren Zahlen abgeleitet werden können.

Kommentare (2)

Jonas

25 Februar 2014 um 01:00

Danke für den Post. Ich bin auch der Meinung, dass die Verschmelzung von Time-Tracking und Scrum-Artefakten ein Antipattern ist.

    Franziska Meyer

    Franziska Meyer

    7 März 2014 um 19:35

    Hallo Jonas, danke für die Bestätigung, dass ich mit dieser Beobachtung nicht allein bin!

×

Updates

Schreiben Sie sich jetzt ein für unsere zwei-wöchentlichen Updates per E-Mail.

This field is required
This field is required
This field is required

Mich interessiert

Select at least one category
You were signed up successfully.