Absolutes Schätzen in Personendaten PT ist immer die schlechteste aller Möglichkeiten. Hierbei müssen ein oder mehrere Entwickler abschätzen wie viele Tage die Entwicklung einer Software in Anspruch nimmt. Es gilt PT = (Dauer der Entwicklung in Tagen) x (Am Projekt beteiligte Personen).

Eine solche Abschätzung ist meist vor Beginn des Projektes notwendig, um auf dieser Basis eine Entscheidung treffen zu können, ob das Projekt umgesetzt werden kann oder nicht.

Nachteile des absoluten Schätzens

Das menschliche Gehirn tut sich mit absolutem Schätzen sehr schwer. Lässt man mehrere Personen getrennt voneinander die Länge eines Gegenstandes schätzen, so erhält man in der Regel sehr unterschiedliche Angaben, die häufig sehr weit von der korrekten Länge entfernt sind. Lässt man die gleichen Personen jedoch schätzen, wie lang der Gegenstand im Verhältnis eines anderen Gegenstandes ist, verbessern sich die Schätzungen deutlich. Es ist nunmal einfacher abzuschätzen, ob ein Gegenstand doppelt so lang wie ein anderer Gegenstand ist, oder ob er 50 cm lang ist.

Wichtig zu verstehen ist auch, dass PT nicht die Einheit ist, in der Anforderungen geschätzt werden. Nicht die Anforderung dauert Zeit, sondern die Umsetzung der Anforderung. Die Umsetzung der Anforderungen geschieht in Tasks, die wiederum etwas gröber zu Arbeitspaketen zusammengefasst werden können.

Das heißt, eine Schätzung in Personentagen ist nur dann möglich, wenn bereits die Arbeit identifiziert wurde, die zur Umsetzung der Anforderung notwendig ist. Dies verlangt jedoch ein gewisses Maß der Vorab-Analyse, um Anforderungen in Arbeitspakete umzuwandeln. Das heißt, bei der Schätzung muss man sich bereits einige Gedanken dazu machen, wie man eine Anforderung umsetzt. Sinnvollerweise sind diese Vorüberlegungen auch zu dokumentieren, um dem Team bei der Umsetzung Anhaltspunkte zu geben. Man legt sich also bereits sehr früh auf die Umsetzung fest, was in einer agilen Welt durchaus zu Problemen führen kann.

Bei der Erstellung von Arbeitspaketen ist zudem darauf zu achten, dass das menschliche Gehirn zur Vereinfachung neigt. Bei größeren Arbeitspaketen werden Details eher ausgeblendet, so dass die Unterschätzung von Arbeitspaketen zunimmt, je größer sie geschnitten sind. Aus diesem Grund empfiehlt es sich bei Schätzungen in PT, die einzelnen Anforderungen vor der eigentlichen Schätzung möglichst klein zu brechen, um so möglichst viele der Details und Probleme verstanden zu haben, die für höhere Aufwände verantwortlich sein könnten. Eine solcher Breakdown der Arbeitspakete verursacht dabei natürlich selbst Kosten. Ob sich dieser Aufwand im Einzelfall lohnt, insbesondere wenn die Aufwandsabschätzung darüber entscheidet ob das Projekt überhaupt gestartet wird, muss im Einzelfall entschieden werden.

Eine sehr interessante Methode zum absoluten Schätzen, auf die ich durch die Lektüre von Clean Coder (Robert C. Martin), aufmerksam geworden bin, ist PERT.

Leider hatte ich bisher noch keine Gelegenheit, PERT praktisch einzusetzen. Sobald ich es einmal selbst ausprobiert habe, schreibe ich gerne einen Artikel darüber.

Im nächsten Artikel geht es aber ersteinmal um das relative Schätzen mit Hilfe von Story Points.