Was ist Agile Schätzung?

Unabhängig davon, ob ein Team ein Produkt oder ein Projekt entwickelt, müssen wir beantworten: „Wann können wir es abgeschlossen haben?“ oder „In welchem Umfang können wir es zu einem bestimmten Zeitpunkt liefern?“ Genau wie bei traditionellen Entwicklungsmodellen müssen wir die Arbeitslast schätzen, bevor wir ein Projekt beginnen.

Agile Schätzung hat die folgenden drei Merkmale:

Team-orientierte gemeinsame Schätzung

In ScrumEntwicklung teilen das Team die Verantwortung und arbeiten gemeinsam an jedem Sprint. Daher verwenden Agile-Teams gemeinsame Schätzungstechniken, um die Arbeitslast zu schätzen. Die gemeinsame Schätzung verwendet typischerweise Planning Poker als Werkzeug, bei dem das Team gemeinsam ein Schätzspiel spielt. Planning Poker gilt als eine der effektivsten und anspruchsvollsten Techniken zur Schätzung der Aufwandsintensität in AgileEntwicklung. Sie besteht aus einer Reihe von Fibonacci-ähnlichen Zahlen: 0, 0,5, 1, 2, 3, 5, 8, 20, 40, ?, ∞. Jedes Deck enthält vier Sätze dieser Fibonacci-Zahlen, die für die Nutzung durch bis zu vier Teammitglieder konzipiert sind.

Genauigkeit der Gruppen- gegenüber Einzelschätzung

Eine Studie zur Genauigkeit der Aufwandschätzung zwischen Einzelpersonen und Gruppen in einem Softwareprojekt-Experiment zeigte, dass 20 Softwarefachleute derselben Firma die für die Umsetzung eines bestimmten Softwareprojekts erforderliche Arbeitszeit getrennt schätzten. Die Teilnehmer hatten unterschiedliche Hintergründe und Rollen, und das Softwareprojekt war bereits zuvor umgesetzt worden. Später wurden sie in fünf Teams zusammengefasst. Jedes Team diskutierte und kombinierte sein Wissen, um sich auf eine einzige Schätzung zu einigen.

Ergebnis: Schätzungen, die auf einer Gruppendiskussion basierten, waren genauer als Einzelschätzungen.

Schritte zum Spielen von Planning Poker

1. Jedes Teammitglied erhält ein Set Karten mit: 0, 0,5, 1, 2, 3, 5, 8, 13, 20, 40, ?, ∞ – insgesamt 12 Karten.
2. Der Product Ownerliest die Beschreibung der Benutzerstory oder Funktion vor.
3. Die Teammitglieder diskutieren die Funktion und stellen dem Product Owner Fragen, falls nötig.
4. Nach der Diskussion wählt jedes Mitglied eine Karte, die seine Schätzung darstellt, und zeigt sie gleichzeitig.
5. Wenn die Schätzungen erheblich voneinander abweichen, diskutiert das Team: Stimmen wir überein? Welche Faktoren wurden übersehen? Die Person mit der höchsten oder niedrigsten Schätzung sollte ihre Argumentation vor der nächsten Abstimmung erläutern.
6. Nach der Diskussion kann das Team einen weiteren Durchgang durchführen, bis Konsens erreicht ist.
7. Gehe zurück zu Schritt 2 und beginne mit der Schätzung des nächsten Backlog-Elements.

Schätzung der Größe, nicht der Zeit – Verwendung relativer Schätzung anstelle von absoluter Schätzung

Schätzung ist einfach eine fundierte Vermutung. Wir nutzen alle verfügbaren Kenntnisse und Erfahrungen, um abzuschätzen, wie lange es dauern wird. Statt jedes neue Arbeitspaket isoliert zu bewerten, warum vergleichen wir es nicht mit bereits abgeschlossenen Aufgaben? Menschen sind besser darin, sich an ähnliche Größen zu orientieren, als absolute Größen zu schätzen.

Zum Beispiel: Ist es ähnlich diesem sehr kleinen Objekt? Oder eher wie dieses mittelgroße Projekt? Oder wirklich groß, wie das, das wir letzten Monat abgeschlossen haben? Relative Schätzung reduziert nicht nur die Zeit, die für die Schätzung aufgewendet wird, sondern verbessert auch die Genauigkeit erheblich.

Unser Gehirn ist nicht gut darin, absolute Schätzungen vorzunehmen – wir beziehen neue Dinge, die wir schätzen müssen, immer auf das, was wir bereits kennen.

Schätzung von Story Points

Schätzung der Geschwindigkeit — Aufzeichnung und Durchschnittsbildung der Teamgeschwindigkeit pro Sprint

Die Geschwindigkeit des TeamsGeschwindigkeit ist die Anzahl der Story Points die Scrum-Teamdas tatsächlich in einem Sprint abgeschlossen wird. Die Teamgeschwindigkeit zeigt an, wie schnell das Team arbeitet. Für ein neues Projekt oder ein neues Team (ohne vorherige Geschwindigkeitsaufzeichnungen) können wir 1–2 Sprints durchführen, um eine Anfangsgeschwindigkeit zu messen und festzulegen. Während der Sprintdurchführung dokumentieren wir die Geschwindigkeit des Teams pro Sprint für die zukünftige Planung.

Schätzung der Geschwindigkeit von Benutzerstories

Wir schätzen die Gesamtanzahl der Story Points im Produkt-Backlog. Kennt man die durchschnittliche Geschwindigkeit pro Sprint, kann man berechnen, wie viele Sprints benötigt werden, um das Projekt abzuschließen – und somit die Projektdauer schätzen. Wie in der Abbildung unten gezeigt.

Schätzung der Projektdauer im Scrum