Den zeitlichen Aufwand für ein Projekt abzuschätzen ist in der Regel kein leichtes Unterfangen. Eine Schätzung an sich ist etwas ungenaues. Wüsste man von Anfang an was raus kommt, wäre eine Schätzung unsinnig. In diesem Fall würde man einfach eine sichere Aussage treffen. Schätzungen basieren immer auf Erfahrungswerten. Hat man keine oder wenige, fällt es einem um so schwerer. Auch in agilen Projekten ist notwendig dem Auftraggeber eine Schätzung hinsichtlich Zeit und Budget zu nennen.
Klassisches Projektmanagement
In klassischen Projekten schätzt oft ein erfahrener Projektleiter nach Rücksprache mit einem Entwickler den zeitlichen Aufwand. Dabei wird häufig so vorgegangen, dass die Aufgaben in einzelne Arbeitsschritte aufgeschlüsselt werden. Hierfür wird relativ viel Zeit aufgewendet um sich im Detail zu überlegen, wie etwas umzusetzen ist. Am Ende steht dann ein Schätzwert, der für den zeitlichen Aufwand des Projekts dem Auftraggeber mitgeteilt wird. Entsprechend diesem Wert wird in großen Unternehmen ein Budget eingerichtet. Eventuell wurde noch ein kleiner Puffer berücksichtigt, aber im Normalfall fallen Schätzungen aufgrund des engen Zeit- und Budgetrahmens eher geringer aus.
Dass sich diese klassische Art der Schätzung vor allem in komplexen Projekten oft als unglücklich gewählt erwiesen hat, konnte eventuell der eine oder andere schon am eigenen Leib erfahren. Komplexe Schätzungen sollten nie nur von einer oder zwei Personen (Entwickler und / oder Projektleiter) durchgeführt werden. Ein typischer Entwickler wird in der Regel nur eine Schätzung zu seiner Arbeit - dem Entwicklungsprozess - abgeben können. Andere Tätigkeiten im Team, die zusätzlich zu einer Aufgabe anfallen, von denen er aber keine Ahnung hat (Zeit für das Testen, Bug fixing, Design, Deployment, Projektmanagement etc.) werden bei dieser Schätzung in den seltensten Fällen berücksichtigt. Idealerweise werden Schätzungen immer im Team durchgeführt.
Wie wird in agilen Projekten geschätzt
In agilen Projekten hat der ProductOwner die Aufgabe sein Team mit einer entsprechenden Anzahl an Tasks zu versorgen. Er ist auch zusammen mit dem Team für die Abschätzung verantwortlich. Es gibt verschiedene Möglichkeiten den Aufwand für (komplexe) Schätzungen zu vereinfachen. In diesem Artikel stellen wir drei Methoden zur Schätzung in agilen Projekten vor. Die Basis jeder dieser Methoden sind zum einen die einzelnen User Storys jeweils auf Papier ausgedruckt. Zum anderen Spielkarten mit ausreichenden Kartensets, welche die Fibonacci-Zahlenreihe (1, 2, 3, 5, 8, 13, …100 und Sonderkarten mit 0 und ?) enthalten.
Grundlegendes zu Schätzungen
Bei Schätzungen immer mit dem beginnen, was einem relativ leicht fällt. Das sind meist die Bereiche, die man schon kennt oder die relativ klein sind (gemäß der vereinfachten Fibonacci Zahlen-Folge). Hierbei wird versucht die Komplexität eines Features und nicht den Aufwand (anhand von Stunden- oder Tagesangaben) zu beschreiben. Was man erreichen will ist, dass eine Schätzung im Team gemacht wird um von allen gemeinsam zu hören, wie Komplex das geplante Projekt sein wird.
Keine Angst vor (Fehl-)Schätzungen: Sinn und Zweck einer Schätzung ist es lediglich heraus zu finden, ob der Sprint zuviele Aufgaben enthält oder zu wenige. Je nachdem kann der Aufgabenumfang entsprechend angepasst werden. Die Schätzung ist also hauptsächlich eine vorbereitende Maßnahme. Hat der Sprint begonnen, verliert sie ihre Bedeutung.
Abstrakte, relative Größenschätzung (zur initialen Projektschätzung)
Schätzungen in Scrum werden in der Regel mit Papier und Stift gemacht (nur in Ausnahmefällen am Beamer oder PC). Das setzt auch voraus, dass immer ein kompetenter Ansprechpartner (ProductOwner) anwesend ist, der die geplanten Features dem Team im einzelnen erklären kann.
1. Planning Poker
Der ProductOwner stellt die User Stories vor und klärt mit dem Team eventuell offene Fragen zu den einzelnen User Stories. Das Team hat anschließend die Aufgabe eine Schätzung anzugeben. Damit jeder aus dem Team eine eigene Schätzung abgeben kann, erhält jeder ein eigenes Planning Poker Kartenset. Zur aktuellen User Story überlegt sich jeder den Aufwand und zieht aus seinem Kartenset eine Zahl mit seiner Schätzung. Bewegen sich die Komplexitätsschätzungen der einzelnen Teamies relativ in der gleichen Größenordnung, besteht kein Diskussionsbedarf. Weichen einzelne Schätzungen jedoch stark voneinander ab, ist es notwendig dies untereinander zu diskutieren. Danach gibt es eine weitere Schätzung zur gleichen User Story. Bei einem eingespielten Team geht das Planning Poker relativ schnell von statten. Noch ungeübte “Spieler” brauchen hingegen ein wenig Zeit. Dies sollte man einkalkulieren, je nachdem wie groß das Team ausfällt. Eventuell ist in diesem Fall das Estimation Game eher zur Komplexitätsschätzung geeignet.
2. Estimation Game
Beim Estimation Game gibt es einzelne User Storys auf Papier (Karten), welche geschätzt werden. Diese liegen alle auf einem Stapel und werden von den Entwicklern einzeln gezogen und dem Team vorgelesen und mit dem ProductOwner kurz geklärt ob es auch richtig verstanden wurde. Die einzelnen User Storys werden von dem Team in einer aufeinander bauenden Reihenfolge sortiert auf den Tisch gelegt werden. Während einer vorliest, ist es wichtig, dass die anderen Teammitglieder still sind und zuhören. Es gibt keine Diskussion um die Aufgabe möglichst schnell abzuwickeln. Zu jeder Story eventuell kurz begründen, warum eine an dieser oder jener Stelle gelegt wird. Auf diese Art und Weise entsteht eine Reihenfolge, die vom Team bestimmt wird. Sind alle User Storys abgelegt, werden die jeweiligen Aufwände (Komplexität) mit den Fibonacci-Zahlen geschätzt. Der Vorteil des Estimation Games gegenüber dem Planning Poker liegt darin, dass man mit noch Scrum Unerfahrenen Teammitgliedern, zu einem schnelleren Resultat kommt.
3. Magic Estimation
Magic Estimation wird eingesetzt, wenn man mit vielen User Story Karten arbeitet und hier aus zeitlichen Gründen eine schnellere Schätzung benötigt als beim Planning Poker oder beim Estimation Game. Hier besteht nämlich die Möglichkeit die User Story Karten unter dem Team zu verteilen und zu sagen “Ihr habt 10 Minuten Zeit die Karten in entsprechender Reihenfolge zu platzieren. Während dieser Zeit legt jeder aus dem Team seine Karten entlang der vorher abgelegten Fibonacci-Zahlenreihe gemäß seiner Komplexitätsschätzung auf den Tisch oder Boden. Während dieser Zeit gibt es keine Diskussionen untereinander und es findet auch kein Austausch der Karten statt. Jedes Team-Mitglied hat das Recht eine von einem anderen gelegte Karte woanders hin zu legen. Merkt der ProductOwner, dass sich die Team-Mitglieder bezüglich der Platzierung einer User Story uneinig sind, wird diese von ihm zur Seite gelegt und später gemeinsam besprochen. Auf diese Weise entsteht relativ schnell eine Reihenfolge mit einer initialen Projektschätzung, um einen groben Budgetrahmen festzulegen. Wichtig ist hier jedoch, dass aufgrund der initialen Schätzung auf jeden Fall später noch einmal eine genauere Schätzung durchgeführt wird, um dann hinsichtlich des tatsächlichen Zeitaufwands genauere Informationen zu bekommen.
Auf unserer Themenseite gibt es weitere Informationen zur Agilen Produktentwicklung.