Berichte: Schätztreue, Durchlauf und Datenhygiene

Die Berichte sind ein eigener Bereich mit sechs Reitern, und jeder Reiter beantwortet genau eine Frage: Portfolio, Projektbericht, Durchlauf, Zeit und Kapazität, Requests und Service, Datenhygiene. Hier erzähle ich vor allem von den Reitern hinter dem Portfolio und von den Entscheidungen, die in den Zahlen stecken.

Der Projektbericht: ehrlich statt hübsch

Der Projektbericht fragt: Reicht die Iteration, und schätzen wir systematisch zu niedrig? Er zeigt die Verteilung über die Statuswerte, die alten offenen Vorgänge, den Restaufwand je Iteration und die Schätztreue.

Die Verteilung nutzt die Statuswerte, die ihr selbst pflegt, nicht die groben Systemstatus.

Ein klassischer Burn-down zeigt Tag für Tag, wie viel Arbeit in einer Iteration noch übrig ist. Genau das kann GODAV Pro nicht, denn der Rest wird nicht für jeden Tag festgehalten. Ich hätte die Kurve aus den heutigen Werten zurückrechnen können, dann hätte sie hübsch ausgesehen. Sie wäre aber erfunden gewesen. Deshalb gibt es einen Burn-down je Iteration: wie viel geplant war, wie viel übrig blieb und wie viel Kapazität da war. Bei abgeschlossenen Iterationen ist der Rest das, was in die nächste übertragen wurde, bei der laufenden der heutige Stand.

Positiv heißt zu niedrig geschätzt. Ab 10 Prozent wird es gelb, ab 25 Prozent rot.

Die Schätztreue vergleicht Schätzung und tatsächlich gebuchte Stunden. Die naheliegende Rechnung wäre falsch gewesen: Wer beim Buchen einen Restaufwand einträgt, setzt die Schätzung auf „bisher gebucht plus Rest“. Am Ende stimmt sie dann fast immer, und die Frage „schätzen wir zu niedrig?“ wäre nicht mehr zu beantworten. Gemessen wird deshalb gegen die ursprüngliche Schätzung, die vor jeder Korrektur. Außerdem zählen nur erledigte Vorgänge, die selbst geschätzt sind und Buchungen haben, und die Abweichung wird über die Summen gerechnet. Dreißig kleine Aufgaben mit großer Abweichung sollen ein großes, gut geschätztes Epic nicht überstimmen.

Durchlauf: der Median statt des Mittelwerts

Der Reiter „Durchlauf“ fragt, wo sich Vorgänge stauen. Er zeigt die Cycle Time, also die Zeit vom Beginn der Arbeit bis zum Abschluss, und die Lead Time, die Zeit vom Anlegen bis zum Abschluss, jeweils je Vorgangsart. Dazu kommen der Durchsatz je Kalenderwoche und die Zahl der begonnenen, aber nicht fertigen Vorgänge je Person.

Für die Zeiten nehme ich den Median, nicht den Durchschnitt. Ein einziger Vorgang, der ein Jahr lang liegen geblieben ist, zieht den Durchschnitt von zwanzig Vorgängen um Wochen nach oben. Der Median sagt dagegen, wie lange ein gewöhnlicher Vorgang braucht. Begonnene Arbeit, an der niemand hängt, steht in der Personenliste ganz unten und gelb. Solche Vorgänge stauen sich nach meiner Erfahrung am zuverlässigsten.

Zeit und Kapazität: Wer sieht wessen Soll?

Hier wird gebuchte Zeit gegen das Soll aus dem Arbeitszeitplan gestellt, je Person und Woche. Spannend war die Frage, wer welche Zeile sehen darf. Ein Administrator sieht alle, jeder andere sich selbst vollständig. Wer in einem Projekt alle Zeiten sehen darf, bekommt die anderen Personen dazu, aber nur mit den Stunden aus diesem Projekt und ohne Soll. Das Recht öffnet die Buchungen im Projekt, nicht den Arbeitsvertrag eines Menschen. Und Teilstunden gegen das volle Soll gestellt ergäben eine falsche Auslastung, keine vorsichtige.

Das Soll beginnt übrigens mit dem Anlegen des Kontos und endet heute. Ein Tag, der noch nicht war, schuldet nichts. Sonst stünde jeder Montag bei einem Fünftel Auslastung.

Datenhygiene: die Voraussetzung für den Rest

Der letzte Reiter ist mir der liebste, weil er die anderen fünf erst brauchbar macht. Er zeigt, was nachgepflegt werden muss: Vorgänge ohne Zuweisung, ohne Zieltermin, ohne Schätzung, ohne Bewegung, Ideen, über die niemand entschieden hat, und Storys ohne Release.

Gelb und nicht rot: Ein Befund ist Arbeit zum Nachpflegen, kein Fehler.

Zwei Regeln darin:

• „Ohne Bewegung“ zählt auch Kommentare. Ein Kommentar ändert den Vorgang selbst nicht, ist aber Bewegung. Ein lebhaft diskutierter Vorgang soll nicht als liegen geblieben gelten.
• „Ohne Release“ gibt es nur in Projekten, die Releases führen. Ein Projekt ohne Releases hat keine Lücke, es arbeitet einfach ohne Auslieferungsstände. Ohne diese Bedingung bestünde der Befund fast nur aus Vorgängen, bei denen nichts zu tun ist.

Außerdem

• Jede Zahl in jedem Reiter ist auf die Projekte beschränkt, die du sehen darfst. Deshalb stehen die Berichte allen offen und nicht nur Administratoren.
• Ein kumulatives Flussdiagramm fehlt bewusst. Dafür bräuchte es eine Statushistorie, und die gibt es noch nicht.