TotalOrder: Konsequent vergleichend schätzen

Absolutes Schätzen führt unweigerlich zu Druck. Denn aus absoluten Schätzungen werden Ergebnisversprechen abgeleitet.

Ob der absolute Schätzwert für den Aufwand zur Umsetzung einer User Story „8 Stunden“ lautet oder „8 Story Points“ oder „medium size“ ist unerheblich. Falls es nicht ohnehin schon offiziell zum Vorgehensmodell gehört, wird irgendwer irgendwann darauf kommen, die Story Points oder T-Shirt Größen umzurechnen in reale Zeit. Und spätestens dann steht eine klare Erwartung im Raum: „Achso, ihr schätzt den Gesamtaufwand für die 5 User Stories auf 37 Story Points? Dann wird die Umsetzung wohl 5 Tage dauern. Denn beim letzten Mal habt ihr 41 Story Points in 5 Tagen geschafft und davor 35 Story Points.“ Und so eine Erwartung macht dir Druck. Du musst ja jetzt eine Punktlandung machen - und zwar unter ungewissen Umständen des Tagesgeschäftes.

Das Problem dabei ist nicht, dass jemand eine Erwartung hat, wann etwas fertig sein wird. Das Problem ist, dass er in der Schätzung ein Versprechen sieht. Die Gleichung im Kopf lautet „Weil die Entwickler 37 Story Points schätzen, versprechen Sie konkludent, die User Stories in 5 Tagen umzusetzen.“

Die, die umsetzen sollen, werden nach einer absoluten Zahl gefragt. Das ist das Problem. Denn die, die da gefragt werden, wissen weder einen genauen Wert, noch haben Sie eine Ahnung vom Risiko, das in den User Stories steckt oder in ihrem Tagesgeschäft der nächsten 2, 3, 5 Tage.

Es heißt nicht umsonst Softwareentwicklung und nicht Softwarebäckerei. Denn Softwareentwicklung ist eine forschende und entwickelnde Tätigkeit, Softwareentwickler sind vor allem Wissenschaftler und Ingenieure in dem, wie und warum sie arbeiten. Nur zu einem sehr kleinen Teil sind die Handwerker, die geradlinig und absehbar einen Plan umsetzen.

Aber ich will mich hier nicht weiter auslassen über die Unmöglichkeit, die Nachteile und auch den Unsinn des absoluten Schätzens in der Softwareentwicklung. Das hat Vasco Duarte ausführlich in seinem Buch NoEstimates: How To Measure Project Progress Without Estimating getan.

Lieber möchte ich dir ein Tool vorstellen, von dem ich glaube, dass damit ehrlichere Ergebnisse erzielt werden können, wenn jemand wissen will, wie es um den Aufwand oder wahrgenommenen Wert von User Stories geht.

Vergleichendes Schätzen

Ich bin gegen das absolute Schätzen, wo man schlicht im Dunkeln tappt. Das ist meistens in der Softwareentwicklung der Fall. Die Schätzung ist einfach nicht genau genug, d.h. mit vielleicht nur 5-10% Fehler behaftet.

Damit will ich aber nicht sagen, dass du als Softwareentwickler gar keine relevantes Gefühl hast, was Umsetzungsaufwand oder -dauer für User Stories angeht. Nur solltest du dich eben darin nicht überschätzen.

Wenn ich fragte „Wie lange brauchst du, um a) eine Funktion zur Addition von ganzen Zahlen in einem Array zu schreiben, b) eine Funktion zur Umwandlung von römischen Zahlen in Dezimalzahlen zu schreiben, oder c) einen automatischen Spielgegner für Tic Tac Toe zu schreiben?“, dann würde ich nichts auf absolute Antworten geben. „a) 5 Minuten, b) 30 Minuten, c) 1 Tag“ wären für mich kaum besser als gewürfelte Zahlen in ihren absoluten Werten.

Einer Eigenschaft deiner Antworten würde ich allerdings trauen: ihrer Ordnung.

Du hättest mit deinen Zahlen die User Stories in eine Ordnung gebracht, eine so genannte Totalordnung (engl. total order). Die aus meiner Sicht zentrale und durchaus belastbare Aussage wäre: „Ich schätze, ich brauche für c) länger als für b) und für b) länger als für a).“

Die Aufwände verhielten sich also so: c) > b) > a).

Das nenne ich auch vergleichendes Schätzen. Denn mehr tust du nicht: du vergleichst geschätzte Aufwände und ordnest danach die User Stories.

Wie groß du die Aufwände absolut schätzt, ist uninteressant. Ob du in Zeit oder Story Points oder T-Shirt Größen denkst, ist uninteressant.

Einzig und allein zählt am Ende die relative Größe der zugeordneten Werte.

Vergleichendes Schätzen im Team

Ein solches Schätzen oder eher nicht Schätzen (#noestimate) funktioniert auch im Team. Dafür werden die persönlichen Totalordnung zu einer gesamten verrechnet.

Nehmen wir an, es stehen diese User Stories zur Umsetzung im Raum: A,B,C,D,E.

Die werden von drei Entwicklern „in Ordnung gebracht“, aber wie zu erwarten, in mehr oder weniger unterschiedliche:

• Peter: C,B,D,A,E
• Paul: B,C,D,E,A
• Maria: D,C,B,E,A

Daraus ergibt sich dann als „total total order“ ;-)

• Gesamt: C,B,D,E,A

Die Rechnung ist ganz einfach. Für jede User Story werden die Positionsindizes addiert und anschließend die User Stories nach diesen Summen aufsteigend sortiert:

• A: 4+5+5=14
• B: 2+1+3=6
• C: 1+2+2=5
• D: 3+3+1=6
• E: 5+4+4=13

Falls User Stories dieselbe Indexsumme haben sollten, ist es egal, wo sie in der Gesamtordnung stehen. Die könnte für das Beispiel also auch lauten: C,D,B,E,A.

(Sobald mehr User Stories zu ordnen sind oder mehr Entwickler teilnehmen, tritt der Fall gleicher Summen aber eher selten ein.)

Über das Gesamtergebnis lässt sich nun natürlich trefflich diskutieren. Ist das nicht ohnehin eines der Ziele von Schätzrunden: Entwickler ins Gespräch bringen?

Im Gegensatz zum absoluten Schätzen ist beim vergleichenden Schätzen aber kein Schaden entstanden. Es liegen keine absoluten Werte vor, es können keine Ergebnisversprechen abgeleitet werden, es entsteht durch das Schätzen kein Druck.

Dennoch ist wertvolle Information entstanden. Ein PO gewinnt sicherlich einen Hinweis für seine Priorisierung aus so einer Totalordnung. Zum Beispiel: „Oh, interessant, ich hätte nicht gedacht, dass die User Stories C und B so aufwändig eingeschätzt werden. Das ist irgendwie im Widerspruch zu dem verhältnismäßig geringen Wert, den ich ihnen beimesse.“

Totalordnung in der Praxis

Man kann solch vergleichendes Schätzen natürlich mit Post-Its an einer Wand machen. Die User Stories werden in irgendeiner Reihenfolge aufgehängt und trägt jeder Entwickler (allgemeiner: Stakeholder) auf die Zettel die Nummer des Platzes ein, auf der er/sie eine User Story sieht.

Kann man so machen - finde ich aber erstens ineffizient und zweitens ineffektiv.

Ineffizient, weil man sich an der Wand mit den Post-Its bei der Ordnung im Wege steht. Und weil man bei mehr als 3-4 User Stories schnell den Überblick verliert; man muss ja die Totalordnungen im Kopf simulieren, bevor man Positionen zuweist. Das ist nervig zeitraubend und anstrengend.

Ineffektiv, weil man bei einer Simulation von Totalordnungen im Kopf suboptimale Ergebnisse erzielt. Man sieht ja nichts vor sich, es fehlt also Information. Außerdem wird das Ergebnis verfälscht, weil man schon Zuweisungen anderer auf Post-Its sehen kann, die die eigene Entscheidung beeinflussen können.

Besser ginge es, wenn jeder einen Satz mit User-Story-Karten in die Hand bekäme und vor sich auf dem Tisch physisch ordnen könnte. Da stünde man sich nicht im Weg, da müsste man nicht simulieren. Doch das ist aufwändig in der Produktion und Beeinflussung durch Abgucken kann immer noch passieren.

Totalordnung im Web

Deshalb habe ich mit Kollege Florian Böhmak ein kleines online Tool geschrieben, das ein vergleichendes Schätzen ganz einfach macht. Egal, ob du mit Stakeholdern um einen Tisch sitzt oder ihr verteilt in aller Welt seid, mit TotalOrder ist ein „Schätzprojekt“ (oder besser: ein #noestimates-Projekt) schnell aufgesetzt und in eine gesamte Totalordnung gebracht.

Schau dir das Video an, in dem ich die Benutzung von TotalOrder in 4 Minuten beschreibe:

Zusammengefasst:

1. Der Product Owner legt ein Projekt an und trägt darin die zu ordnenden Elemente ein (z.B. User Stories).
2. Der PO schickt an die Stakeholder, deren Meinung er zu einer Totalordnung haben will, den invitation link, den TotalOrder generiert.
3. Die Stakeholder bringen die Elemente in ihre je persönliche Totalordnung.
4. Der PO verfolgt, wie sich die gesamte Totalordnung nach Einreichung jeder persönlichen verändert.

Und am Ende können alle über das Ergebnis diskutieren und entscheiden, was das konkret bedeutet, z.B. in Bezug auf die Priorisierung oder Arbeitsorganisation.

Die Webanwendung ist derzeit ein Hobbyprojekt Florian und mich (Stand 1.2.2018). Wir probieren daran Clean Code Development Ansätze aus - und freuen uns, wenn gleichzeitig etwas Nützliches für die Community entstehen sollte.

Probiere TotalOrder doch einfach mit in deinem Team aus und lass mich wissen, was ihr dabei für Erfahrungen macht. Über Feedback-Email würde ich mich freuen.

Happy TotalOrdering! #noestimate rulez! :-)