Agile Entwicklung: Gutes Schätzen geht auch remote

Seite 3: Bucket-Schätzung mit Online-Tools

Inhaltsverzeichnis

Die im vorherigen Abschnitt beschriebene Kartenlogik setzt eigentlich einen Tisch und Karten – also Meeting-Teilnehmer in einem Raum – voraus. Online lässt sich diese Methode beispielsweise mit Whiteboard-Software simulieren.

Die erste Karte ist schon gesetzt. Die nächsten werden Schritt für Schritt hinzugefügt. Sie sind dann das Online-Äquivalent von Haftnotizen, die man auf eine Metaplanwand oder einen Tisch kleben kann. Das Ergebnis kann wie in Abbildung 4 aussehen:

Ergebnis einer Bucket-Schätzung (Abb. 4)

Für solche Schätzungen kann man im Grunde jede Online-Whiteboard-Software verwenden. Miro, Mural und Ziteboard seien hier nur als Beispiele genannt.

Wieder muss man sich fragen, ob man die Informationen über sein Projekt online speichern möchte. Auch in den Whiteboard-Werkzeugen muss man sich mit einer E-Mail-Adresse anmelden. Wenn man allerdings PowerPoint ein wenig anders gebraucht als beabsichtigt, kann es für eine solche Schätzung verwenden (s. Abb. 5).

Beispiel für eine Bucket-Schätzung in PowerPoint (Abb. 5)

Man legt für jeden funktionalen Block eine Folie mit möglichst großer Schrift an. Dafür bieten sich die Vorlagen für Titelfolien an. In der Ansicht „Folien sortieren“ lassen sich Folien in kleinen sogenannten Thumbnails anzeigen. Zusätzlich ist es möglich, Abschnitte zu definieren, die wie bei den Online-Whiteboards Gleichheit oder Größenbeziehungen anzeigen.

Sicherlich ist ein solcher Gebrauch von PowerPoint nur ein extremes Hilfsmittel für eine Bucket-Schätzung. Ähnliches kann man auch mit Excel erreichen, wenn man in der Diskussion einzelne Zellen kopiert, die für die Funktionsblöcke stehen, um sie gemäß ihrer Komplexität zu sortieren. Es zeigt, dass man auch remote gute Unterstützung für Schätzungen finden kann, ohne Online-Tools verwenden zu müssen, die der Auftraggeber oder Arbeitgeber nicht zulässt.

Videos by heise

Hat man seine Buckets gefunden, kann man ihnen Zahlen zuordnen. Wiederum bietet es sich an, eine angepasste Fibonacci-Folge zu verwenden. Aber auch Zahlenfolgen mit Verdoppelungen oder anderen Faktoren können durchaus zum Einsatz kommen. Ausprobieren führt hier zum Ziel. Für die Buckets in Abbildung 4 bieten sich die Zahlen 3, 5, 8, 13, und 20 an. Sie können verschiedene Aufwände repräsentieren – Personenwochen oder auch Sprints. Aus der eigenen Erfahrung heraus empfiehlt es sich, in Personenwochen zu schätzen. Das Schätzen in Teamsprints kann sich schwierig gestalten, wenn sich das Projekt wie im Beispiel des Artikels noch am Anfang befindet, man noch kein Team und keine zugehörige Team-Velocity hat. In wirklich großen Projekten mit vielen Teams bietet sich aber ein Schätzen in Teamsprints eher an als eines in Personenwochen.

Während der Diskussion sollte man auch Risiken festhalten und dokumentieren. Ähnlich wie die User-Stories kann man sie auf virtuellen Haftnotizen festhalten. Man sollte gleich bewerten, ob das Risiko hoch, mittel oder niedrig ist. In der Diskussion ergeben sich dann entsprechende Aufschläge auf die Schätzung, zum Beispiel 30 Prozent für ein niedriges, 50 Prozent für ein mittleres und 100 Prozent für ein hohes Risiko. Das Ergebnis eines solchen Vorgehens zeigt Abbildung 6.

Beispiel für eine Bucket-Schätzung mit zugeordneten Zahlen und Risiken (Abb. 6)

Ist das Budget bewilligt, können die Beteiligten in die detaillierte Planung einsteigen. Abgrenzungen des Projekts und Domänendefinitionen sind hierfür notwendig. Die groben funktionalen Blöcke müssen in Epics herunter gebrochen werden. Es bietet sich an, dies schon durch erste Teammitglieder durchführen zu lassen. Idealerweise stehen schon die sogenannten 3 Amigos zur Verfügung: Product Owner, Entwickler und Tester. Bei größeren Projekten mit mehreren Teams sollten auch übergreifende Rollen wie Architektur- und UX-Experten in den Schätzungs- und Planungsprozess einbezogen werden.

Die Teamvertreter brechen die funktionalen Blöcke in Epics herunter und markieren wiederum Risiken, aber insbesondere Abhängigkeiten zu anderen Teams oder auch Projekten. Die Epics lassen sich im Bucket-Verfahren gemäß ihrer Komplexität bewerten. Abhängigkeiten gehen als Risiko in die Bewertung ein. Auch andere Risiken – wie Nichtverfügbarkeit von Entwicklungs- und Testumgebungen, Lernaufwände für unbekannte Technologien – fließen in die Bewertung ein. Wieder kann man virtuelle Haftnotizen für die Schätzung verwenden. Lässt sich für die Teamschätzungen nur Excel oder auch PowerPoint verwenden, kann man die Notizfunktionen nutzen, um solche Risiken festzuhalten.