Anforderungen schätzen – aber WIE?

Es gibt wohl kaum ein kontroverseres Thema in der agilen Softwareentwicklung als des Schätzen der Anforderungen. Diesen Eindruck habe ich jedenfalls, wenn ich täglich mit Product Ownern, Entwicklerteams und Scrum Mastern über die Methodik und die verwendeten Einheiten beim Schätzen diskutiere. Welche Einheit ist die beste? Sollen abstrakte Größen, wie Story Points, oder lieber absolute Größen, wie Stunden oder Personentage, für die Schätzung von Anforderungen verwendet werden? Ich habe das Gefühl, dass sich hier keine einheitliche Herangehensweise etabliert hat. Ein Blick in die Literatur zeigt auch hier keine einheitliche Meinung über die Einheit der Schätzungen:

Kent Beck sagt zum Schätzen in der 2. Auflage seines Buches “Extreme Programming Explained” folgendes:

“The first edition of Extreme Programming Explained had a more abstract estimation model, in which stories cost one, two, or three points. […] I prefer to work with real time estimated now, making all communication as clear, direct and transparent as possible.”

Boris Gloger vertritt in seinem Buch über Scrum die Meinung, dass nur eine Schätzung in abstrakten Größen (keinesfalls Zeiteinheiten) zum Schätzerfolg führt.

Mike Cohn legt sich in seinem Buch “Succeeding with Agile: Software Development Using Scrum” nicht genau fest und lässt die Entscheidung ob “Story Points” oder “Ideal Work Hours” verwendet werden bei den Teams.

Ken Schwaber und Mike Beedle unterstützen die Ansicht von zeitunabhängigen Schätzungen in ihrem Buch “Agile Development with Scrum“:

“Duration is not considered in Scrum. Work remaining and date are the only variables of interrest.”

Es sieht also fast so aus als ob hier jeder seinen eigenen Weg finden muss. Aber wo liegen die Vor- und Nachteile von konkreten bzw abstrakten Einheiten in der Praxis?

Vorteile Nachteile
Konkrete Einheiten (Personentage, Ideal Work Hours, Stunden,…)
  • Hohe Transparenz
  • Einfache Kommunikation des Aufwands
  • Kompatibilität zu traditionellen Methoden
  • Wenig Konflikte da bekannte Methode
  • Selbstbetrug durch festhalten an unrealistischen Schätzungen
  • Ungenaue Schätzungen selbst bei sehr erfahrenen Entwicklern
  • Steigerung der Velocity nicht feststellbar

 

Abstrakte Einheiten (Story Points, Kühe, Bäume,…)
  • Fokus auf Funktionalität, die dem Kunden einen Nutzen liefert
  • Genauere Schätzungen auch von unerfahrenen Entwicklern
  • Steigerung der Velocity feststellbar
  • Inkompatibilität mit Arbeitsweise anderer Abteilungen
  • Klärung was Einfluss auf die Größe der Schätzung hat ist oft schwierig (Funktionalität, Komplexität, Rahmenbedingungen,…)
  • Erhöhtes Konfliktpotential

Unabhängig welche Methode zur Anwendung kommt, sind Referenzen (z.B. Referenz User Stories) eine große Hilfe um vergleichbare Schätzungen über die Zeit und über Teams hinweg erzielen zu können. Neben der Einheit spielt auch die Schätz Methode eine wesentliche Rolle – also wie der eigentlich Prozess des Schätzens abläuft. Dazu aber in einem anderen Blogpost mehr.

Advertisements

Published by

Stefan Wunder

My name is Stefan Wunder and I am a passionate Agile coach from Graz, Austria. I have been working in the software industry since 2006, being an agile practitioner since 2011. I have experience with pioneering Agile, transitioning teams from waterfall to Agile, as well as working with established high performance teams within scaled agile enterprises. I worked with co-located as well as with dispersed teams, in start-ups, medium sized companies and big global enterprises in various industries. Currently I am working as enterprise Agile coach at AVL List GmbH.

One thought on “Anforderungen schätzen – aber WIE?”

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s