Soll ein Entwickler Aufwandsschätzungen machen?

Aufwandsschätzungen?
Geschrieben von Yuliya Mijuk am 22.05.2014

"Soll ein Entwickler Aufwandsschätzungen machen?" – das ist der Titel eines Entwickler-Stammtisches mit dem Namen ArchiB@le, der am 25.5. in Basel stattfindet.

Ich habe dieses Event zufällig auf XING entdeckt und gedacht: "Wieso stellt jemand diese Frage? Zweifelt man daran, dass man eine Release- oder Projektplanung braucht? Will man über den möglichen Genauigkeitsgrad bei der Aufwandsschätzung diskutieren? Will man Erfahrungen darüber austauschen, welche Schätzeinheiten, z.B. Stunden, ideale Manntage, Story Points oder andere mir unbekannte Einheiten, sich besser durchgesetzt haben und warum?"

Wie es aussieht wäre dieses Event etwas für mich...

Was spricht gegen eine Aufwandschätzung?

  • Eine genaue Schätzung ist erfahrungsgemäß nicht oder nur selten möglich.
  • Schätzung kostet Entwicklungszeit. Während das Team schätzt, kann es nicht wertschöpfend arbeiten.
  • Mehr Investment in die Schätzung erhöht die Genauigkeit nur gering, da viele Projekte nicht miteinander vergleichbar sind.

Nutzen:

  • Der Kunde braucht Information über Kosten und Risiko, um eine Entscheidung zu treffen.
  • Der Schätzungsprozess hilft dem Team, die Komplexität der Aufgabe als Ganzes und im Detail zu verstehen.
  • Die Schätzung liefert dem Team wichtige Informationen, um sich zu organisieren.

Wenn man über die Aufwandsschätzung spricht, muss man zwischen der Schätzung des Product Backlogs und der Schätzung des Sprint Backlogs unterscheiden.

Die Schätzung des Sprint Backlogs ist die Sache des Teams. Meine Erfahrung zeigt, dass viele Teams keine Schätzung brauchen, um sich im Sprint organisieren zu können und die eigenen Fortschritte zu verfolgen. Sie splitten ihre Backlog Items in die Tasks mit der Einschränkung, dass die Tasks nicht länger als einen Tag dauern. Es gibt aber auch Teams die ihre Tasks im Sprint Planning in Stunden schätzen, weil sie sich sicherer fühlen, wenn die Anzahl der verplanten Stunden einigermaßen mit der Sprintdauer übereinstimmt. Jedenfalls reden wir hier von einem "kann" und nicht einem "soll".

Sollen Entwickler nun Aufwandsschätzungen für das Product Backlog machen? Auch wenn man der Meinung ist, dass der Nutzen vom Schätzen für die Entwickler zu gering ist und die Kontras überwiegen, so kann man die Tatsache nicht bestreiten, dass der Kunde eine verlässliche Aussage über den Preis und/oder die Dauer seiner Bestellung braucht. Und wenn man als Firma am eigenen Produkt entwickelt, möchte man eine Ressourcenplanung haben. Die Entwickler sollen also die Frage nach dem Preis und/oder der Dauer beantworten können, doch können sie selbst entscheiden wie sie zu dieser Antwort kommen.

Es muss nicht die traditionelle direkte Schätzung von Dauer sein. Denn genau bei dieser Art von Schätzung werden die oben genannten Kritikpunkte am sichtbarsten.

Man kann eine relative Schätzung (z.B. Story Points) benutzten – Entwicklungsaufwand für ein Backlog Item im Vergleich zu anderen schätzen. Die Gesamtzahl der Schätzpunkte, die man in einem Sprint umgesetzt hat, dient dann als Orientierungswert für die Festlegung des Liefer- bzw. Release-Datums. Diese Art Schätzung liefert nach meiner Erfahrung nicht weniger genaue Planungswerte als die direkte Zeitschschätzung und geht schneller. Sie fördert besser die Teamdiskussionen über die Inhalte der Backlog Items und geht einfacher über die Lippen, denn es ist einfacher zu sagen "die Aufgabe ist komplex" als "Wir brauchen für diese Aufgabe viel Zeit".

Oder man geht noch weiter und schliesst sich der #NoEstimates Bewegung an und beantwortet die Frage nach Preis und Dauer

  • auf der Basis von Erfahrungen (z.B. Preis/Dauer für die Art von Arbeit, die man regelmässig zu einem festen Preis und mit einem festen Team ausführt)

oder

  • durch die preislichen bzw. zeitlichen Einschränkungen des Projekts (z.B. "Wir haben nur 100\$, was könnt ihr uns dafür bauen?" oder "Das Volksmusik Festival findet in 3 Monaten statt und die Volksmusik-Festival-App muss ein Tag vor dem Festivalanfang veröffentlicht werden")

#NoEstimates setzt Vertrauen zwischen dem Kunden und dem Auftragnehmer wie auch ein stabiles Entwicklungsteam voraus. Und das ist die Situation, dass jeder Entwickler sich wünscht. Insofern ist #NoEstimates in meinen Augen das Ziel, dass man anstreben sollte.

Wie Neil Killick es so schön sagt: "It is not about ditching estimates. It is about improving the way we work such that estimates become redundant".

Yuliya Mijuk

Über die Autorin

Yuliya Mijuk

Yuliyas berufliches Leben fing gleich mit Scrum an. Sie ist Certified Scrum Professional und hatte ihre Zertifizierung als ScrumMaster in 2006. Nach dem Computerlinguistikstudium an der LMU München kam sie 2004 zu WEB.DE, wo zu dieser Zeit die Umstellung auf Scrum stattfand. Später hat Yuliya als ScrumMaster und Scrum Coach bei SPRiNT iT und bei billiger.de gearbeitet.