Agile Entwicklung: Aufwand schätzen

Als Softwareentwicklungs-Dienstleister hören wir bei der lise Gmbh von unseren Kunden oft Fragen wie "Wann ist die User Story X fertig?", "Wie viele User Stories sind bis zum Zeitpunkt Y umgesetzt?", "Was kostet Feature Z?" oder, um H.P. Baxxter zu zitieren: "How much is the fish?".

Wie ich als Entwickler und Scrum-Master bei der Beantwortung dieser und ähnlicher Fragen vorgehe, darin soll dieser Blogartikel einen Einblick geben.
 

Wieso überhaupt schätzen?

Wie die Überschrift schon sagt, gebe ich bei der Beantwortung der Eingangsfragen keine Versprechen à la "Ihre Software ist in sechs Monaten und vier Tagen fertig", sondern eine Schätzung ab. Das liegt daran, dass man bei der Entwicklung von Softwareprodukten in einem komplexen Umfeld unterwegs ist, in dem es einfach nicht möglich ist, alle Arbeiten, Anforderungen und Unwägbarkeiten im Vorfeld genau vorauszusehen und einzuplanen.

Man könnte argumentieren, dass SoftwareentwicklerInnen tagtäglich an der Umsetzung von User Stories arbeiten und somit wissen sollten, welche Story wie lange bis zur Fertigstellung benötigt und entsprechend ein ganzes Projekt geplant werden kann. Aber jedes Projekt ist unterschiedlich. Man arbeitet mit verschiedenen Kunden zusammen, es gibt andere Anforderungen an die Software, die sich mal mehr oder mal weniger ändern, dann werden unterschiedliche Technologien eingesetzt und so weiter. 

User Stories schätzen: Welche Prinzipien wende ich an?

Da niemand eine 100-prozentig verlässliche Aussagen treffen kann, sondern wir alle darauf angewiesen sind, zu schätzen, stellen sich zwei Fragen: „wie geht man am besten dabei vor?“ und „welche Prinzipien helfen dabei, eine treffende Schätzung abzugeben?“

Vier dieser Prinzipien stelle ich nun näher vor:

1.) Die Umsetzenden schätzen

Die Leute, die eine Software entwickeln, sollen auch das Schätzen übernehmen. Es ist zwar üblich, dass bei der Planung eines Projektes in der Management-Ebene ein zeitlicher Rahmen gesteckt wird. Allerdings sind diese Personen selbst gar nicht bei der Umsetzung involviert und dementsprechend fehlt das fachliche Wissen, um eine passende Schätzung abzugeben. Die SoftwareentwicklerInnen sind also in diesem Fall diejenigen, die über dieses Wissen verfügen und deshalb den Aufwand wesentlich besser schätzen können.

2.) Relative Schätzungen sind besser als absolute

Menschen tun sich generell schwer, Dinge absolut zu schätzen. Wenn man schätzen soll, wie viele Meter hoch der Kölner Dom ist, ist dies deutlich schwieriger als einzuordnen, dass er höher als ein Einfamilienhaus ist, aber kleiner als das Empire State Building. Analog kann man bei der Softwareentwicklung genau einschätzen, dass die Umsetzung einer Nutzerverwaltung komplizierter ist als eine Log-In Maske. Eine genaue Stundenanzahl für das Projekt zu schätzen fällt hier jedoch deutlich schwerer.

3.) Die erste Schätzung soll unabhängig erfolgen

Um eine treffsicheres Ergebnis zu erhalten, wenn eine User Story mit mehreren Leuten geschätzt wird, ist es sehr wichtig, dass jede Person unvoreingenommen vorgeht.. 

Ein Szenario: Wenn reihum jedes Team-Mitglied seine Schätzung laut äußern soll, traut sich die zweite Person möglicherweise nicht, eine deutlich abweichende Schätzung abzugeben. Besonders dann, wenn die erste Person deutlich erfahrener ist. 

Die erste Person setzt hier also einen Anker und beeinflusst bzw. „primt“ die Schätzung der zweiten Person. Schätzen die Team-Mitglieder unbeeinflusst voneinander, ergeben sich ehrlichere Einschätzungen und größere Abweichungen voneinander sind wahrscheinlicher. Diese werden gemeinsam diskutiert und den Gründen für die Unterschiede kann nachgegangen werden. Eventuell hat jemand eine einfachere Lösung für die Umsetzung der User Story oder es kommt heraus, dass noch kein gemeinsames Verständnis darüber herrscht, was genau umgesetzt werden soll.

4.) Komplexität statt Aufwand schätzen

Der erste Impuls ist oft, eine User Story in Stunden oder Tagen zu schätzen - also in zeitlichem Aufwand. Das Schätzen der Komplexität bietet demgegenüber viele Vorteile: es ist objektiver, über die Zeit konstanter und personenunabhängig. Das trägt dazu bei, dass User Stories, die den höchsten Wert stiften, früher angegangen werden.

In welchen Einheiten wird der Aufwand geschätzt?

Die Methode, User Stories in Stunden zu schätzen, hat den Nachteil, dass die Schätzung nicht mehr unabhängig von dem oder der Entwickelnden ist. Außerdem führt sie schnell dazu, dass ein Rechtfertigungsdruck aufgebaut wird, wenn für die Umsetzung länger benötigt wird als ursprünglich geschätzt. Oder die Qualität leidet, weil man in der geschätzten Zeit bleiben möchte.

Eine alternative Möglichkeit ist, die User Stories in sogenannten Story Points zu schätzen. Diese Einheit ist abstrakt und kann von Team zu Team variieren. Wenn in Story Points geschätzt wird, wird meist die sogenannte Cohn-Skala genutzt, die an die Fibonacci-Reihe angelehnt ist. Hierbei ist jeder Wert ca. 60% größer als sein Vorgänger. Das Besondere daran: Es hat sich gezeigt, dass diese Verhältnismäßigkeit der Art und Weise entspricht, wie Menschen schätzen. Das führt daher zu akkurateren Schätzungen in den Projekten.

Die Cohn-Skala weicht ab dem Wert 20 von der Fibonacci-Reihe ab. Das bringt zum Ausdruck, dass mit zunehmender Größe eine genaue Schätzung immer schwieriger wird. Ebenso nimmt die Unsicherheit zu. Die Cohn-Skala eignet sich außerdem wunderbar, um relativ zu schätzen. Wurde z.B. die Nutzerverwaltung aus dem obigen Beispiel auf 13 Story Points geschätzt, würde die Login-Maske mit 3 Story Points geschätzt.

Welche Schätz-Methoden gibt es?

Eine populäre Methode, um im Team zu schätzen und dabei die genannten Prinzipen einzuhalten, ist das sogenannte Planning Poker. Dieses eignet sich besonders, um im Backlog während eines Projekts gemeinsam eine vergleichsweise kleine Menge an User Stories zu schätzen („Refinement“).

(Lust aufs Pokern bekommen? Einfach unten für den Newsletter eintragen und wir schicken Ihnen ein Planning Pokerset zu! Nur solange der Vorrat reicht.)

Beim Start eines Projekts möchte man aber meist auch eine Schätzung über den Gesamtumfang haben -  zumindest eine grobe. Dazu eignet sich Magic Estimation. Damit kann man in relativ kurzer Zeit das gesamte Product Backlog schätzen und so einen Überblick erhalten. Als Alternative zu Magic Estimation lässt sich das sogenannte Team Estimation Game einsetzen. Was diese Methoden ausmacht, werden wir in einem zukünftigen Blog-Beitrag behandeln.

Nicht unerwähnt soll an dieser Stelle bleiben, dass es als Gegenentwurf die "No Estimates" Bewegung gibt, die Schätzungen aus verschiedenen Gründen kritisch betrachtet und dafür wirbt, auf diese zu verzichten.
 

Was kann man mit Schätzungen anfangen?

Abschließend stellt sich die Frage, welchen Nutzen wir aus den Schätzungen ziehen können. Eine Möglichkeit: Voraussagen über die Zukunft zu machen. Damit können dann genau solche Fragen beantwortet werden, wie in der Einleitung gestellt. Man kann etwa die Velocity (Anzahl Story Points, die in einem Sprint umgesetzt wurden) aus vergangen Sprints heranziehen, um mit dieser Information den Umfang des nächsten Sprints zu planen. Ebenso kann man hochrechnen, welche User Stories bis zu einem bestimmten Zeitpunkt umgesetzt sind. Dabei ist es wichtig, auf Daten aus der Vergangenheit zurückgreifen zu können, auf die sich diese Voraussagen stützen. Im Laufe eines Projekts nimmt außerdem die Unsicherheit mit der gesammelten Erfahrung ab und die Voraussagen werden somit verlässlicher.

Schätzungen lassen sich außerdem bei der Priorisierung kommender Aufgaben nutzen, vor allem wenn in mehreren Dimensionen (z.B. Komplexität und Business Value) geschätzt wird. Und schließlich trägt das gemeinsame Schätzen zu einem besseren Verständnis der User Stories bei und hilft Transparenz bei den Projekt-Beteiligten zu schaffen!

Übrigens: Mehr zu Schätzungen, Scrum und agilen Arbeitsweisen finden Sie in unseren Workshops der lise Academy

Ich will agiles Entwickeln lernen!