Im letzten Beitrag habe ich geschrieben, wie Sie mit #NoEstimates starten können, wenn Sie derzeit Story Points verwenden. Heute möchte ich über verschiedene Arten von Schätzungen schreiben. [Vielleicht interessiert Sie auch: Was ist eine Schätzung überhaupt?]

Es gibt verschiedene Techniken, um eine Aufwandsschätzung zu erstellen, und die Schätzungen selbst sind unterschiedlich. Wir können diese Techniken und Schätzungen entlang eines Spektrums mit verschiedenen Achsen klassifizieren:

• Direkt vs. Indirekt: Drückt die Schätzung den Aufwand direkt aus (Zeit, Kosten, ...) oder drückt sie etwas anderes aus, aus dem sich der Aufwand ableiten lässt (Größe, ...).
• Konkret vs. Abstrakt: Ähnlich wie der Punkt oben: Ist der Aufwand eine konkrete Messgröße oder etwas Abstrakteres?
• Feingranular vs. Grobgranular: Wie groß sind die Dinge, die Sie schätzen (Stunden, Tage, Monate, ...).
• Einfach vs. Aufwändig: Wie schwer ist es, eine Schätzung zu erstellen? Wie schwer ist sie zu verstehen?

Heute möchte ich über einige Techniken schreiben, um Aufwandsschätzungen zu erstellen. Ich werde auch versuchen, sie in das obige Spektrum einzuordnen.

Zeit direkt schätzen

Hier versuchen Sie, die Zeit zu schätzen, die die Implementierung eines Features oder das Beheben eines Bugs benötigt. Die Einheit der Schätzung ist „Personentage” (oder etwas Ähnliches). Manchmal erstellt die Projektmanagerin oder der Lead-Entwickler die Schätzung aufgrund ihrer Erfahrung, manchmal erstellt das Team die Schätzung gemeinsam.

Im Spektrum: Direkt - Konkret - Grobgranular - Aufwändig

Dieser Ansatz hat viele Probleme. Die größten zwei: Es ist sehr schwer (oder vielleicht sogar unmöglich), genaue Zeitschätzungen zu erstellen. Wir Menschen sind einfach sehr schlecht darin. Und alle Arbeit neigt dazu, die verfügbare Zeit zu füllen. Das bedeutet: Wenn Sie die benötigte Zeit überschätzen, wird die Aufgabe wahrscheinlich die längere Zeit in Anspruch nehmen.

Ich war in zwei Projekten als Berater tätig, in denen die Zeit direkt geschätzt wurde. In einem hat es überhaupt nicht funktioniert. Eine Woche vor dem Release war alles zu 99% fertig. Am Tag des Releases haben wir festgestellt, dass wir den Release um drei Monate verschieben mussten.

Im anderen schien es sehr gut zu funktionieren: Wir haben fast zwei Jahre lang alles pünktlich und im Budget abgeschlossen, obwohl wir die Schätzungen nicht erstellt haben – der Chefarchitekt hat das getan. Es war für den Kunden völlig vorhersehbar. Wie haben wir das geschafft? Nun, die Schätzungen waren stark aufgepolstert. Wir saßen oft tagelang herum und… kompilierten…, weil neue Arbeit erst ankam, nachdem die alte Arbeit eigentlich fertig sein sollte. Schlimmer noch: Es war für unsere Kunden nahezu unmöglich, etwas zu ändern, das bereits geplant war. Das ist nicht gut.

Aufgaben in Stunden schätzen

Eine Variante des Obigen, aber feiner granular. Sie schätzen keine großen Features, sondern kleine Engineering-Aufgaben. Die Einheit der Schätzung ist „Stunden”. Die Personen, die die Arbeit erledigen, erstellen die Schätzungen. Sie können dann z. B. ein Sprint-Burndown-Chart auf Basis der verbleibenden Stunden erstellen.

Im Spektrum: Direkt - Konkret - Feingranular - Einfach

Als ich zuerst etwas über Scrum gelernt habe, habe ich gelernt, dass man Aufgaben in der Sprint-Planung auf diese Weise schätzen sollte. Jemand anderes hat mir einmal gesagt, man solle Aufgaben in Vierteltagen schätzen. Weil zwei Stunden total sinnvoller als Einheit sind als eine Stunde… Wirklich?

Die Probleme sind im Grunde dieselben wie oben, aber es gibt noch ein weiteres: Die Zeit, die für die Schätzung aufgewendet wird, ist wahrscheinlich verschwendet. Warum sollte man eine Schätzung für etwas erstellen wollen, das ohnehin nur ein paar Stunden dauert? Ich denke – oder ich hoffe –, dass das heute niemand mehr macht.

Einfach die Aufgaben zählen

Anstatt die Zeit zu schätzen, die eine Aufgabe benötigt, zählen Sie einfach die Anzahl der Aufgaben. Eine Aufgabe sollte ohnehin weniger als einen Tag dauern, daher können Sie sicher davon ausgehen, dass die meisten Aufgaben ungefähr gleich groß sind. Sie können dann z. B. ein Sprint-Burndown-Chart auf Basis der verbleibenden Aufgaben erstellen.

Im Spektrum: Indirekt - Abstrakt - Feingranular - Einfach

Das löst einige der oben genannten Probleme, aber Sie müssen weiterhin alle Aufgaben früh identifizieren, um aussagekräftige Statistiken zu erhalten. In einem zeitlich begrenzten Planungsmeeting schaffen Sie das möglicherweise nicht. Und es ist vielleicht sogar agiler, nicht einmal zu versuchen, alle Aufgaben im Voraus zu identifizieren – das lässt Optionen offen.

Soweit ich weiß, haben die meisten Teams inzwischen aufgehört, Aufgaben zu zählen, und erstellen ihre Burndown-Charts auf Basis der verbleibenden Story Points oder der Anzahl der verbleibenden Stories.

Idealzeit + Lastfaktor schätzen

Manche Leute (in den frühen Tagen von Extreme Programming) haben versucht, Features in „idealer Entwicklungszeit” zu schätzen. Die Einheit der Schätzung ist „Personentage” oder „Pair-Tage”. Das Team oder ein Teil des Teams erstellt die Schätzungen.

Im Spektrum: Direkt - Konkret - Grobgranular - Aufwändig

Die insgesamt benötigte Zeit wäre dann viel länger, wegen Unterbrechungen, Fehlern und so weiter. Sie können einen Lastfaktor berechnen, der Ihnen sagt, wie viel länger es (im Durchschnitt) dauern wird, etwas abzuschließen. Ein Lastfaktor von „3” bedeutet, dass Sie für jeden idealen Entwicklungstag 3 reale Tage benötigen.

Fog Creek Software hat früher eine Technik wie diese namens Evidence Based Scheduling verwendet. Ich weiß nicht, ob sie das noch tun, aber soweit ich weiß, ist diese Technik weitgehend aus der Mode gekommen.

„Größe" mit Story Points schätzen

Sie versuchen, die Größe der Arbeit zu schätzen und leiten dann den erwarteten Aufwand aus der geschätzten Größe ab. Die Einheit der Schätzung ist „Story Points”. Das Team kommt auf die Schätzung, oft mit „Planning Poker”.

Im Spektrum: Indirekt - Abstrakt - Grobgranular - Einfach

Mit all den Problemen der direkten, konkreten Schätztechniken haben manche Leute entschieden, dass wir etwas Abstrakteres und Indirekteres brauchen. Also kamen sie auf Story Points.

Die Grundidee ist, dass es schwer sein mag, sich darauf zu einigen, wie lange etwas dauern wird, aber Sie können sich trotzdem auf die Größe der Sache einigen. Angenommen, Sie möchten, dass ich eine Mauer baue, die 10 Meter lang und 2 Meter hoch ist. Ich habe keine Ahnung, wie lange ich brauchen werde, um sie fertigzustellen, aber wir können uns darauf einigen, dass die Mauer 10 Meter lang und 2 Meter hoch ist. Nachdem ich einige Mauern gebaut habe, kann ich Ihnen vielleicht eine durchschnittliche Dauer pro Quadratmeter nennen. Oder ich kann Ihnen sagen, wie viele Quadratmeter Mauer ich in zwei Wochen bauen kann – meine „Velocity” in Story Points.

Das Problem mit dieser Technik ist, dass Ihre Schätzungen wahrscheinlich immer noch sehr ungenau sein werden. Eine Fünf-Punkte-Story kann einen Tag dauern, eine andere zwei Wochen. Manche Leute werden Ihnen sagen, dass sich die Ungenauigkeiten ausgleichen, aber wenn Sie nicht wissen, warum sie das tun, sind Ihre Schätzungen nur Zahlen aus der Luft gegriffen.

Die meisten Teams, die ich bisher beraten habe, haben diese Technik verwendet.

Function Points scheinen ebenfalls die Größe der Anforderungen zu schätzen, sind aber komplizierter und nicht Teil dieses Artikels.

Einfach die Stories zählen

Selbst Story-Point-Schätzungen sind also noch ziemlich ungenau. Und die Schätzung kostet Zeit, die möglicherweise verschwendet ist (d. h. nicht genutzt wird, um Wert für den Kunden zu schaffen). Vielleicht können wir mit etwas noch Abstrakterem und Einfacherem trotzdem aussagekräftige Daten erhalten? Nun, zählen Sie einfach die User Stories.

Im Spektrum: Indirekt - Abstrakt - Grobgranular - Sehr einfach

Wie beim „Einfach die Aufgaben zählen” wollen Sie, dass die meisten Stories ungefähr gleich groß sind. Die Idee ist, dass die Stories, wenn sie einfach genug und gut genug verstanden sind, damit die Entwicklung beginnen könnte, in etwa gleich groß sein werden.

Ihr Planungshorizont wird mit dieser Technik kürzer sein, weil Sie nur detaillierte Stories kurz vor ihrer Umsetzung erstellen wollen. Aber das ist oft kein Problem, weil es Optionen für den längeren Planungshorizont schafft. Oder Sie könnten diese Technik nur für den längeren Planungshorizont verwenden, wo Sie nur größere Features zählen, nicht einzelne User Stories.

Fazit

Alle Techniken können unter bestimmten Umständen Wert bieten. Sie sollten keine von ihnen verwerfen, nur weil sie „zu abstrakt” oder „zu einfach” oder „zu kompliziert” ist.

Aber Sie können sich fragen: „Bekomme ich mit einer einfacheren Technik alle Informationen, die ich brauche?” Und davon ausgehend finden Sie vielleicht Wege, sich zu verbessern.

Haben Sie Fragen? Was bräuchten Sie, um mit etwas Einfacherem zu starten, als Sie derzeit haben? Sagen Sie es mir!