Im ersten Teil des Artikels haben wir uns mit der viel diskutierten Frage auseinander gesetzt, ob beim Estimation der Aufwand oder die Komplexität beurteilt werden sollte. Tatsache ist: Den Aufwand zu schätzen (also die voraussichtliche Dauer der Arbeit) erscheint einfacher, ist vertrauter. Doch es hat viele negative Nebenwirkungen, von der geringeren Flexibilität in der Priorisierung und einer verhängnisvollen Neigung vom Aufaddieren bis zu einer Vernachlässigung der Qualität in der Umsetzung.
Dennoch ist es nicht nur ein Versehen, wenn viele Teams eben doch eine Schätzung des Aufwands anstelle der Komplexität (also der Schwierigkeit der Aufgabe, die Menge an Denkarbeit und Unwägbarkeit) vornehmen. Vielmehr gib es auch einige kritische Argumente, die wir in diesem zweiten Teil des Artikels untersuchen.
Dass von so vielen Teams mehr oder weniger hartnäckig bzw. bewusst der Aufwand anstatt der Komplexität geschätzt wird, hat natürlich Gründe: Es erscheint einleuchtender, ist vertrauter und vor allem einfacher.
Hinzu kommt, dass das obere Management in erster Linie wissen will, wann ein definiertes Produkt fertig ist für die Auslieferung. Hier zu vermitteln, warum Komplexität der sinnvollere Wert ist, um eine plausible Vorhersage erreichen zu können, kostet Kraft und Zeit. Also ist Aufwand schätzen die „entspanntere“ Alternative - auch wenn man hinterher daneben liegt.
Schon das Verständnis dessen, was Komplexität eigentlich ist, ist schwer genug. Sie dann auch noch mit einer numerischen Größe zu versehen - kann das überhaupt gelingen?
Und wie soll eine Komplexitäts-Schätzung, die sich explizit nicht in Zeit umrechnen lässt, dann überhaupt nützlich sein für eine zeitliche Planung? Indem man sich auf Wahrscheinlichkeiten und das Gesetz der großen Zahl verlassen kann!
Denn die Chance, dass eine Story mehr Aufwand kostet, je komplexer sie ist, ist groß. Aber es ist eine Frage der Wahrscheinlichkeit und kann im Einzelfall ganz anders aussehen. Im Mittel aber, nimmt man mehrere Stories zusammen, wird es ungefähr hin kommen.
Dieser bewusste Umgang mit Wahrscheinlichkeiten ist ohnehin die einzig mögliche Strategie in komplexen Systemen, wie die Software-Entwicklung eines ist. Ähnlich wie bei der Wettervorhersage: Auch bei 80% Regenwahrscheinlichkeit muss es nicht regnen. Aber die Chance ist groß.
Wer schätzt, so der Duden, hält etwas für wahrscheinlich oder nimmt eine näherungsweise Bestimmung vor. Und genau darum geht es: Um eine grobe Orientierung. In die Zukunft sehen kann eh niemand.
Wenn diese Vorhersage ohnehin nur eine ungefähre ist, was bringt sie uns dann? Zumal, wenn ich viel Zeit investieren muss, um diese Vorhersagbarkeit überhaupt zu erreichen, durch die regelmäßigen Meetings und die Erhebung und Pflege der Daten für eine belastbare Velocity?
Klar ist, dass letztlich jedes Team selbst entscheiden muss, ob und wie sich die Praxis des Estimations für sie lohnt. Klar ist aber auch, dass es nicht allein um die Benennung von Zahlen geht. Es geht, wie bei so vielen agilen Praktiken, um Feedback: Der Product Owner erfährt, was das Team über eine Story denkt. Ob die Anforderung bereits ausreichend spezifiziert ist, ob das Ganze so machbar ist, oder ob es anders viel einfacher ginge. Und, ja, auch wie §groߧ eine Story ungefähr ist, ob es sich um einen kleinen Fisch oder einen großen Brocken handelt.
Das alles hilft dem PO bei seiner Planung, und dem Team dabei, eine Orientierung zu bekommen, wo es hin geht. Ein gutes Estimation ist eine Einladung an das Team, sich kritisch und konstruktiv mit den mittelfristig anstehenden Aufgaben auseinander zu setzen.
Neben dem dieser nun ausgiebig diskutierten Ausrichtung auf die Komplexität einer Story anstelle des Aufwands gibt es noch einige andere Aspekte, die dabei helfen können Estimations zu einer lohnenswerten Angelegenheit zu machen.
So gilt auch hierbei: Weniger ist mehr. Steht der PO zu Beginn des Estimations mit einem Stapel von 20 bis 30 Stories in der Tür, wird kaum jemand Lust haben, über auch nur eine einzige Story länger als zwei Minuten nachzudenken.
Ein guter, erfahrener PO sollte ohnehin ein so gutes Grundverständnis seiner Themen haben, dass er seinen Stakeholdern selbständig ein ungefähres Feedback über die Komplexität geben kann. Soll heißen: Nicht über jede spontane oder bisweilen auch abwegige Idee muss das gesamte Team diskutieren!
Im gleichen Zusammenhand sollte man darauf achten. dass Stories nicht zu lange zwischen dem Estimation und der tatsächlichen Umsetzung liegen bleiben.
Womöglich lohnt es, sich hier einer Kanban-Praxis zu bedienen und die Durchlaufzeit zu messen: An jeder Story wird vermerkt, wann sie als Idee aufkam, wann sie zuerst besprochen und geschätzt wurde, und wann sie tatsächlich in den Weg in den Sprint gefunden hat. Sammelt man diese Daten über einen gewissen Zeitraum, erhält man ein gutes Gespür für den typischen Weg von der Idee bis zur Umsetzung.
Wer trotz aller Konzentration auf die Komplexität dennoch immer wieder anfängt, Stories in Stunden umzurechnen und die Zahlen zusammen zu addieren, kann mit einem alternativen Maßstab gegensteuern:
Tiere von klein bis groß, von Maus über Schwein bis Elefant können ebenso die Größe einer Story symbolisieren. Oder man verwendet T-Shirt-Größen, von XS bis XL. Diese sind eingängig und verständlich. Um zu entscheiden, wie viele davon in einen Sprint passen, muss man aber auf den Inhalt statt nur das Label schauen.
Und je umfangreicher und stabiler die Datengrundlage aus vorhergehenden Sprints ist, umso besser kann man auch aus der Vergangenheit auf die Zukunft schließen. Damit kann man sich z. B. für die Release-Planung darauf verlassen, wie viele Stories ein bestimmtes Team im Durchschnitt je Sprint schafft.
Dann aber sollte aus dem Estimation Meeting ein Backlog Grooming werden, in dem das Team gemeinsam anstehende Stories durchsieht und bespricht.
Die Einschätzung der Größe mag dann unwichtig geworden sein. Unbedingt relevant aber ist der Austausch über die Inhalte der Stories.
Denn egal wie man es ausgestaltet: Der größte Nutzen ist das frühzeitige Feedback zwischen PO und Team, die Zahlen an den Stories vor allem eine Orientierungshilfe.
Rufen Sie uns an: 030 – 555 74 70 0
