Methoden zur direkten und indirekten Aufwandsschätzung (2)

Indirekte Schätzungen mit Story Points

Eine direkte Schätzung des Entwicklungsaufwands (siehe: Expertenschätzungen) ist von den persönlichen Fähigkeiten des Schätzers abhängig und nicht von der Leistungsfähigkeit des Teams, das für die Entwicklung vorgesehen ist. Im Gegensatz zu einer direkten Schätzung ermitteln indirekte Methoden zunächst die Größe der zu entwickelnden Objekte oder Anforderungen und stellen diese anschließend in Relation zu Erfahrungswerten idealerweise des gleichen Teams aus früheren Sprints. 

Im Fall der Story Point-Methode bewerten Schätzer die Größe von User Stories, jedoch nicht in einer absoluten Maßeinheit sondern relativ zueinander. Beispiel: „Die Auswahl des Zielflughafens und Datums ist eine 1. Die Abfrage verfügbarer Flüge ist im Verhältnis dazu eine 3. Die Buchung eines ausgewählten Flugs ist dann eine 8.“ Die Skala für die zu vergebenden Story Points orientiert sich an der Fibonacci-Folge: 1, 2, 3, 5, 8, 13 und so weiter. Dadurch entfallen kleinteilige Diskussionen und Entscheidungen zwischen den zulässigen Werten werden erleichtert. Gleichzeitig macht die Skala jedoch auch deutlich, dass die Genauigkeit der Bewertung mit zunehmender Größe abnimmt.

Die Berechnung des voraussichtlichen Entwicklungsaufwands auf Basis von Story Points erfordert einen Erfahrungswert, wie viele Story Points das Team unter vergleichbaren Rahmenbedingungen je Inkrement bzw. Sprint umsetzen kann. Dieser Erfahrungswert wird Velocity genannt und nach jedem abgeschlossenen Sprint dadurch aktualisiert, dass die Größe der tatsächlich entwickelten Stories mit der dafür benötigten Zeit ins Verhältnis gesetzt wird.

Eine Aufwandsschätzung durch Story Points hat den Vorteil, dass sie schnell angewendet werden kann und von der aktuellen Leistungsfähigkeit des Teams und nicht einzelner Individuen ausgeht. Durch die permanente Nachkalibrierung der Velocity kann sich diese innerhalb von wenigen Sprints an Veränderungen beispielsweise in der Team-Zusammensetzung oder sonstiger Rahmenbedingungen anpassen.

Ein Nachteil der Methode ist die Detaillierung des Schätzobjekts: eine User Story, die eine Anforderung meist nur umgangssprachlich in einem Satz beschreibt. Unerwartete Komplexität, die erst bei der Umsetzung festgestellt wird, führt dann häufig zu einer Überschreitung des geschätzten Aufwands.

Alternativen:

• Expertenschätzungen
• Indirekte Schätzungen durch Bestimmung des funktionalen Umfangs

Buchempfehlung: "Aufwandsschätzungen in der agilen Softwareentwicklung"