Seite 2: Wirtschaftsplanung

Inhaltsverzeichnis

Eine detailliertere Wirtschaftsplanung verlangt bessere, das heißt detailliertere Abschätzungen. Um für sie Aufwandsabschätzungen abgeben zu können, sollten die Ideen schon weiter ausgearbeitet sein. Die Applikation, der Service oder die Erweiterung sind dann in funktionale Blöcke heruntergebrochen. Mit ihnen sind hier Business-Funktionen wie "Rechnungserstellung" und nichttechnische Komponenten wie "PDF-Generator" gemeint.

Für jeden der Funktionsblöcke wird eine Karte erstellt, die man in der Schätzung verwendet. Empfehlenswert ist es, die Projekte immer getrennt zu behandeln, also nur die Funktionsblöcke eines Projekts zu betrachten. Alternativ kann man mehrere Projekte gleichzeitig schätzen, vor allem dann, wenn es sich um viele kleine handelt.

Eine erste Karte wird auf den Tisch gelegt, weitere Karten werden genommen und diskutiert, ob der Aufwand höher, niedriger oder vergleichbar zu einer gelegten Karte ist. Wenn er höher ist, wird die Karte über die andere gelegt, wenn kleiner, dann darunter. Ist der Aufwand vergleichbar, landet die Karte daneben. Weitere Karten können die Mitspieler neben vorhandene legen, wenn der Aufwand vergleichbar ist. Bei Aufwänden beziehungsweise Komplexitäten, die zwischen zwei Karten liegen, wird die neue Karte zwischen diesen einsortiert.

Als Nächstes suchen die Projektbeteiligten einen Funktionsblock aus, den sie gut kennen, und schätzen ihn gemeinsam über ein Planning Poker ab. Es ist nicht möglich, in User Story Points zu schätzen, da weder ein Team noch User Stories vorhanden sind. Aber es lässt sich die Scrum-Folge (die Folge, die sich für Planning Pokers durchgesetzt hat: 0,5, 1, 2, 3, 5, 8, 13, 20, 40, 100) verwenden und den einzelnen Zahlen so eine Größenordnung eigener Wahl zuordnen, zum Beispiel Personen-Sprints oder Personentage. Aus Sicht der Autorin haben sich hier Personenwochen bewährt. Es ist auch möglich, doppelt, halb und gleich zu verwenden, was dann Folgen von 2, 4 und 8 nach sich zieht. Hier empfiehlt es sich, ein wenig auszuprobieren, was zum jeweiligen Entwicklungsobjekt am besten passt.

Die nebeneinanderliegenden Karten werden nun in ihren einzelnen Reihen (oder sog. Eimern) bewertet, das heißt danach, ob sie wirklich gleich sind oder nicht. Entsprechend ihrer Bewertung wandern sie entweder eins hoch oder eins runter. Ansonsten werden die einzelnen Eimer (siehe Bucket Estimation) den Zahlen der Folge zugeordnet.

Bei der gesamten Diskussion sollte man aufpassen, dass man keine Risiken oder auch Lernaufwände (zum Beispiel für neue Techniken) mitbewertet. Das erfolgt in einem nächsten Schritt oder parallel, also wenn die Beteiligten ohnehin den jeweiligen Block diskutieren.

Man schreibt auf die Kärtchen jeweils das Risiko "Hoch", "Mittel" oder "Klein". Mehr Stufen haben sich nicht bewährt. Lern- oder auch zusätzliche Aufwände für zum Beispiel den Aufbau neuer IT-Infrastrukturen werden ebenfalls in diesen Stufen bewertet. Der Unterschied zu den Risiken ist klar: Risiken können eintreten, Lernaufwände und Ähnliches treten in jedem Fall auf.

Man einigt sich im Vorfeld, was "Hoch", "Mittel" und "Klein" jeweils bedeutet. In der Praxis haben sich die prozentualen Stufen 20, 50 und 80 Prozent bewährt. Die Stufe "Kein Risiko" sollte zu diesem Zeitpunkt eines Projekts nicht auftreten, dazu gibt es so früh einfach noch zu viele Unbekannte. Die zusätzlichen Aufwände mit ihren Stufen kann man in der gleichen Messtabelle wie die Funktionsblöcke bewerten, also zum Beispiel hohe zusätzliche Aufwände mit 5, mittlere mit 3 und kleine mit 2. Keine zusätzlichen Aufwände können natürlich vorkommen (im Gegensatz zum Risiko), zum Beispiel wenn die zu verwendende Technik bekannt ist.