Eine weitere intuitive Schätzmethode ist die «Analogiemethode». Hier werden Erfahrungswerte aus der Vergangenheit bei Projekten mit ähnlichem Inhalt und ähnlicher Grösse und Komplexität genutzt. Weiter fliessen hier Erfahrungen betreffend Fehleinschätzungen aus vergangenen Projekten ein und erhöhen so die Qualität der Schätzungen.

Bei diesem Vorgehen überlege ich, was alles zu tun ist. Dann schätze die Aufwände für die kleinsten Aufgaben und summiere alles auf. So hoffe ich, dass am Ende keine unrealistische Summe herauskommt. Diese Methode macht es einfach, jemanden die Frage «Kann es sein, dass das so lange dauert oder so viel kostet?» zu beantworten und klar zu argumentieren. Je genauer man die Tasks zusammensammelt, desto genauer wird die Schätzung ausfallen. Nachteil ist jedoch, dass diese Schätzmethode sehr viel Zeit in Anspruch nehmen kann. Auch der Umfang des Projekts muss bereits recht klar und strukturiert sein (eine Unterteilung in Arbeitspakete sollte vorliegen). Weiter kann man sich bei dieser Methode verzetteln, da viele kleine Schätzungen viel schwerer fallen können, als eine grobe High-Level-Schätzung. Muss man seinem Vorgesetzten jedoch erklären, woher die utopischen Zahlen kommen, ist diese Methode sehr hilfreich und transparent.

Einige meiner Kunden geben bereits ein Budget und eine Dauer des Projekts vor und lassen keinen Spielraum für anderweitige Schätzmethoden. Daher gibt es den «Top-Down-Ansatz»: Vom Groben zum Feinen, sprich das Ganze nochmal andersherum. Sind also die Gesamtaufwände zum Beispiel vorgegeben oder grob bekannt (Budget, Zeit der Umsetzung), unterteilt man den vorgegebenen Gesamtaufwand auf die Einzelbereiche des Projekts (Entwicklung, Testing, Definition, Defect-Handling, Rollout usw.) auf und prüft, ob die Zahlen halbwegs Sinn ergeben. Benötigen dann z.B. bereits 2 der 4 Teilbereiche mehr Ressourcen oder Zeit als vorgegeben, sind die vorgegebenen Rahmenbedingungen unrealistisch und nicht einzuhalten.

Diese Methode wird meist in Scrum-Teams und agilen Umfeldern eingesetzt. Hier schätze ich nicht allein oder mit einzelnen Experten. Das ganze Team nimmt spielerisch teil und taxiert mit Hilfe von speziellen Spielkarten Aufwände für Tasks (oder/und Epics und User Stories) für den anstehenden Sprint. Sog. Story Points widerspiegeln das Ergebnis der Schätzung und illustrieren, ob ein Aufwand sehr klein, mittel oder gross sein könnte (gerne wird auch mit Grössen wie «T-Shirt-Size» gearbeitet). Ein Story-Point ist eher mehr Metrik als ein Mass für Zeit oder Geld. Oftmals hat man nicht ausreichende Informationen. Daher behandelt man den Aufwand als relative Grösse. Als Basis dient eine Referenz-Story oder ein Referenz-Task, für die/den der Story-Point Wert bekannt und gemeinsam bereits definiert wurde. Mit Zahlen auf den Spielkarten geben die Team-Member ihre Meinung preis, ob das zu schätzende Arbeitspaket oder die User Story mehr oder weniger Aufwand als der Bezugspunkt bedeutet. Durch Diskussionen nähert man sich einem Mittelwert an, der vom ganzen Team mitgetragen wird und einer genauen Schätzung am nächsten kommt.