Aufwand, nicht Komplexität

Wohltuend. Jahrelang an “Lehrbuch” CSMs aufgerieben. Immer wieder die gleichen Diskussionen. Nein liebe CSMs, es geht beim Schätzergebnis (Story Points) nicht um Komplexität. Diese spielt natürlich eine wichtige Rolle – aber es geht im Ergebnis immer um Aufwand und Kosten.

(Oft habe ich mich gefragt, wer den CSMs diesen Unsinn erzählt hat… )

Wahnsinn, wie innovativ ich schon vor Jahren war ;-) – damals mit einem Kollegen (Wolfgang for president!) ein Excel-Spielzeug ähnlich wie es Jeff Sutherland jetzt promotet erstellt und dann Aussagen wie “It’s Effort, Not Complexity” von Mike Cohn.

Wirklich befriedigend, diese Bestätigung zu bekommen. Schade nur, dass wir gerade zurechtgestutzt werden, nachdem wir die Probleme transparent gemacht haben. Ist die Gegenreaktion der Linie, vgl. auch “Die dunkle Seite von Scrum”.

5 thoughts on “Aufwand, nicht Komplexität

  1. Toll, und nur weil es jetzt “der große” Mike Cohn himself sagt, muss es also sofort richtig sein? Ich bin immer noch für Komplexität statt Aufwand, weil der Aufwand gleich die zeitliche Komponente enthält und die Komplexität nicht. Und weil Leute zu gerne dann anfangen irgendwelche Puffer einzuplanen, wenn sie mit Zeiteinheiten rechnen.

    Wie will man vor allem wirklich den Aufwand abschätzen? Nein, mich hat die “Neuerung” von Mike Cohn und dir noch nicht wirklich überzeugt und es gibt auch Stimmen, die das auch weiterhin kritisch sehen. Auch ein Mike Cohn kann sich irren.

    Ich bin mal auf deine Argumentation gespannt :)

  2. Zitat eines Arbeitskollegen zu diesem Thema:


    Hm. Wer nur sagen will, wie komplex etwas ist, der wird halt in Talern ausbezahlt statt in Euro.

    Das Problem mit dieser Sichtweise ist: Am Ende spielt der Aufwand eine Rolle, nur eine “Komplexität” zu schießen ist Thema verfehlt.

  3. Ich verwende seit Jahren Komplexität und nicht Aufwand – ganz ehrlich – es geht um die Schätzung des Teams – und denen ist Aufwand ziemlich egal. Aufwand ist etwas für die Manager und hat in der internen Planung des Teams nichts verloren. Der Sprint hat eine definierte Dauer mit X Resourcen = Aufwand / Sprint = Kosten / Sprint. Pro User Story erstellt das Team dann die Tasks = geschätzter Aufwand / US. Business Value im Vergleich zur Komplexität ist eine grobe Einschätzung.
    Wenn jetzt plötzlich wieder das Team mit Aufwand “belästigt” wird können wir gleich wieder andere Projektmanagement Methoden verwenden. Da werden meiner Meinung nach wieder einmal Äpfel mit Birnen verglichen – ich bleibe bei der seit vielen Jahren erfolgreich eingesetzten Komplexitiätsbeurteilung. Das haben die Unternehmen bei denen ich Scrum eingeführt habe bisher immer sehr geschätzt – hey und auch die Krawattenträger haben es irgend wann einmal kapiert ;-).

  4. Nachtrag zum vorherigen Post – demnächst heißt es dann nicht mehr Business Value sonder Priorität – weil das Projektmanager die ihre Denkweise nicht ändern wollen einfach so gewohnt sind.

  5. Nun, es ist grundsätzlich gut/sehr sinnvoll, zunächst in abstrakten Größen zu schätzen und geschätzte Elemente zueinander in Bezug zu setzen. Bei der Einschätzung einer relativen Größe ist natürlich „Komplexität“ ein wichtiges Element. Letztendlich wird IMHO aber Aufwand geschätzt. Wie lange muss ich mich wahrscheinlich mit dem Thema XYZ beschäftigen? Soweit so gut, das wird schon seit langem von erfahrenen Schätzern so gehandhabt und wurde lediglich in die neuen agilen Methoden übernommen.

    Die Argumentation mit „Komplexität“ halte ich – sorry – für eine Blendgranate, um von den schlechten Schätzpraktiken „sag mir JETZT wie viele Stunden für das 3. Release 2011 benötigte werden!“ abzulenken und greift in der oft diskutierten Absolutheit zu weit. Wie gesagt: Komplexität ist ein Element des Aufwands. Vielleicht ist es auch einfach nur ein Übersetzungsfehler: „Compexity“ wird nicht nur mit „Komplexität“ übersetzt sondern eben auch mit „Aufwand“ ;-)

    Eine Team, dem Aufwand egal ist, hat entweder einen goldenen Sponsor gefunden oder lebt an der Realität vorbei. Diese Abkopplung von der Realität habe ich auch mehrfach beobachten können – meist war diese Sichtweise nicht von Erfolg gekrönt.

    Jeder in einem agilen Team muss an einem positiven ROI interessiert sein (= Creating Value). Hierzu gehört unbedingt die Betrachtung des Aufwands. Das eine Aufwandsschätzung mittels SPs ungenau ist, kann hingenommen werden. Eine Plausibilitätsüberprüfung erfolgt ja im Planning 2 beim Herunterbrechen in die Tasks.

    Die Business Value und die Priorität sind zudem mitnichten synonym zu verwenden. Abhängig von einer Aufwandsschätzung kann eine Story mit niedriger Business Value sehr wohl eine höhere Priorität bekommen. Business Value wird genutzt, um ein Potential zu beschreiben. Priorität, um eine Reihenfolge zu definieren.

Comments are closed.