Seite 3: Scope- und Domain-Definition, Team-Onboarding, Projekt-Kick-off

Inhaltsverzeichnis

Ist das Budget bewilligt, können die Projektverantwortlichen an die Planung gehen. Zunächst grenzt man den Scope ab, um sicherzugehen, dass Erwartungen und lieferbare Ergebnisse nicht zu weit auseinanderlaufen. Anschließend definiert man die Domänen und ordnet sie den jeweiligen Teams zu. Innerhalb der Domänen können dann erste Teammitglieder, idealerweise "The 3 Amigos" Product Owner, Development und Testing, die Zahlen der Wirtschaftsplanung verifizieren.

Beim Projekt-Kick-off kann man den Bucket-Ansatz wie oben beschrieben oder auch ein klassisches Planning Poker auf Epics anwenden. Wieder stehen hier keine User Story Points zur Verfügung. Handelt es sich um ein relativ kleines Projekt, das nur ein Team (hier Teams mit fünf Personen, größere Teams arbeiten in der Regel ineffizient, da zu viel Zeit verwendet werden muss, um sich gegenseitig auszutauschen) benötigt und dieses sich gut kennt, empfiehlt es sich, ein bekanntes Epic zu verwenden und es mit 5 zu bewerten. Die Epics werden – wie User Stories – bezüglich ihrer Komplexität bewertet: nicht in User Story Points, sondern in Epic Points. Sind die Teams noch nicht (vollständig) "an Bord" oder neu zusammengestellt, muss man auf Personentage oder Personenwochen zurückgreifen. Wichtig ist, dass die Diskussionsbeteiligten später auch im Projekt arbeiten. Leider lässt sich das bei den Zeitpunkten "Idee" und "Wirtschaftsplanung" selten realisieren.

Ähnlich wie zuvor in der Wirtschaftsplanung empfiehlt es sich, zu jedem Epic Risiko und Lernaufwand abzuschätzen. Der Lernaufwand lässt sich sogar pro Teammitglied ziemlich genau beziffern und separat ausweisen. Das Risiko kann man wieder mit ähnlichen Aufschlägen beziffern wie bei der Wirtschaftsplanung. Allerdings sollten keine Epics mehr in die Risikostufe "Hoch" eingestuft werden, da offene Fragen sowohl aus Business- als auch aus technischer Sicht in der Zeit zwischen Wirtschaftsplanung und Projektstart geklärt wurden.

Es kann im Gegensatz zum Zeitpunkt der Wirtschaftsplanung Epics geben, die in die Stufe "Kein Risiko" eingeordnet werden, da die technischen und Business-Fragen erfolgreich geklärt wurden. Daraus folgt, dass die Epics in die Risikostufen "Mittel", "Klein" und "Kein Risiko" eingeordnet werden, die dann 50, 20 und 0 Prozent entsprechen. Achtung! Null-Prozent-Risiko heißt nicht, dass es keine Schätzungenauigkeit mehr gibt. Es heißt nur, dass man in diesem spezifischen Bereich nicht mehr mit bösen Überraschungen rechnet. Nochmals: Die Projektbeteiligten schätzen, sie messen nicht.

Implementierung

Während der Implementierung verwendet man die klassischen Ansätze aus den agilen Vorgehensmodellen: etwa Planning Poker. Dabei sollte es dem Team überlassen sein, in welchen Größen es schätzt. Teams, in denen sich die handelnden Personen nicht kennen, tun sich mit User Story Points erfahrungsgemäß schwer. Solche, die sich gut kennen, können auch auf der Basis der verzehrten Gummibärchen schätzen und liegen trotzdem richtig. Ein stetes Herantasten und Messen der Velocity des Teams sind notwendig.

Man kann immer wieder versuchen, andere Größen als ideale Personentage zu verwenden. Dann kann man auch auf die oben beschriebenen Bucket- oder T-Shirt-Size-Prinzipien zurückgreifen. Wichtig ist, dass das Team das Gefühl hat, gehört zu werden. Wenn es ständig zu niedrige oder auch zu hohe Aufwände schätzt, liegt das nicht an Schätzmethodik, sondern an der Umgebung, in der das Team arbeiten muss. Ständige Unterbrechungen durch "Production Issues" sind dafür nur ein Beispiel.