Story Points und Schätzungen

Mit einer guten Schätzung können Produktinhaber Effizienz und Wirksamkeit optimieren. Darum ist sie überaus wichtig. 

Dan Radigan Dan Radigan
Themen durchsuchen

Schätzungen abzugeben ist schwer. Für Softwareentwickler ist es einer der schwierigsten Aspekte ihres Jobs – wenn nicht gar der schwierigste. Es müssen verschiedene Faktoren in Betracht gezogen werden, die Produktinhaber dabei unterstützen, Entscheidungen zu treffen, die sich auf das gesamte Team und das Unternehmen auswirken. Wenn derart viel auf dem Spiel steht, ist es kein Wunder, dass alle – von den Entwicklern bis zum leitenden Management – darauf bedacht sind, ihre Schäfchen ins Trockene zu bringen. Aber das ist ein Fehler. Die Schätzung in Agile ist einfach nur eine Schätzung und kein Blutschwur.

Auch wenn das Unterschätzen einer Aufgabe nicht durch Wochenendarbeit kompensiert werden muss, sollten wir uns einige Methoden für möglichst präzise agile Schätzungen ansehen.

Zusammenarbeit mit dem Product Owner

In der agilen Entwicklung ist der Produktinhaber dafür verantwortlich, die Prioritäten im Backlog festzulegen. Das Backlog ist eine sortierte Liste der Aufgaben mit kurzen Beschreibungen aller gewünschten Features und Fehlerbehebungen für ein Produkt. Produktinhaber erfassen die Anforderungen des Unternehmens, verstehen aber nicht immer die Details der Implementierung. Mit einer guten Schätzung kann der Produktinhaber den Aufwand für jedes Aufgabenelement neu bewerten und damit wiederum die relative Priorität jedes Elements besser beurteilen.

Wenn das Entwicklerteam den Schätzungsprozess beginnt, kommen für gewöhnlich Fragen zu Anforderungen und User Storys auf. Und das ist gut so: Diese Fragen helfen dem gesamten Team, die Aufgaben besser zu verstehen. Insbesondere der Produktinhaber kann durch das Aufteilen von Aufgabenelementen in granulare Unterelemente und Schätzungen anhand von Story Points einfacher Prioritäten für alle (auch potenziell versteckte!) Arbeitsbereiche festlegen. Oft ordnet der Produktinhaber die Elemente im Backlog neu an, nachdem er die Schätzungen vom Entwicklerteam erhalten hat.

Agile Schätzung ist Teamarbeit

Es ist sehr wichtig, alle Teammitglieder (Entwickler, Designer, Tester, Deployer ... einfach alle) einzubeziehen. Jedes Teammitglied bringt eine eigene Sichtweise für das Produkt und die für die Bereitstellung einer User Story erforderlichen Aufgaben ein. Wenn beispielsweise das Produktmanagement ein scheinbar einfaches Projekt wie die Unterstützung für einen neuen Browser implementieren möchte, müssen das Entwicklungs- und das QA-Team einbezogen werden, da sie die Erfahrung haben und wissen, welche Probleme dabei möglicherweise auftauchen können.

Und auch bei Designänderungen sollte nicht nur das Designteam zurate gezogen werden, sondern auch das Entwicklungs- und das QA-Team. Wenn ein Teil des Produktteams aus dem Schätzungsprozess ausgeschlossen wird, sind die Schätzungen weniger präzise. Außerdem leidet die Teammoral, weil sich wichtige Beteiligte ausgeschlossen fühlen. Und das wirkt sich wiederum auf die Qualität der Software aus.

Achte also darauf, dass dein Team nicht unter Schätzungen zu leiden hat, die in einem Vakuum erstellt wurden. Denn das ist ein sicherer Weg zum Misserfolg!

Story Points oder Stunden

Herkömmliche Softwareteams erstellen Schätzungen in einem zeitbasierten Format, also in Tagen, Wochen und Monaten. Viele agile Teams sind jedoch zu Story Points übergegangen. Mithilfe von Story Points wird der relative Aufwand einer Aufgabe in einem fibonacciartigen Format bewertet: 0, 0,5, 1, 2, 3, 5, 8, 13, 20, 40, 100. Auch wenn es widersprüchlich klingen mag, ist diese Abstraktion tatsächlich hilfreich, da das Team damit die Schwierigkeit einer Aufgabe strenger beurteilt. Hier sind einige Gründe, die für die Verwendung von Story Points sprechen:

  • Nicht projektrelevante Aufgaben für ein Teammitglied, die sich unweigerlich in unseren Tagesablauf einschleichen, wie E-Mails, Meetings und Interviews, werden bei Datumsangaben nicht berücksichtigt.
  • Datumsangaben schaffen eine emotionale Verbindung, während eine relative Schätzung eine emotionale Verbindung vermeidet.
  • Jedes Team schätzt Aufgaben nach einem unterschiedlichen Maßstab ab, was bedeutet, dass die (in Punkten gemessene) Velocity ganz selbstverständlich unterschiedlich ist. Das ermöglicht allerdings, die Velocity als politisches Druckmittel einzusetzen.
  • Wenn ihr euch erst einmal über den relativen Aufwand jedes Story Point-Werts geeinigt habt, könnt ihr ohne lange Diskussionen Punkte zuweisen.
  • Mit Story Points können einzelne Teammitglieder für das Lösen von Problemen belohnt werden – und zwar abhängig von deren Schwierigkeit, nicht von der benötigten Zeit. So konzentriert sich das Team darauf, wertvolle Ergebnisse zu liefern, statt nur auf die Zeit zu achten.

Story Points und Planning Poker

Teams, die mit Story Points beginnen, spielen oft das sogenannte Planning Poker. Bei Atlassian wird Planning Poker regelmäßig im gesamten Unternehmen gespielt. Das Team nimmt eine Aufgabe aus dem Backlog und bespricht diese kurz. Dann überlegt sich jedes Teammitglied im Kopf eine Schätzung. Anschließend halten alle eine Karte mit der Zahl hoch, die der jeweiligen Schätzung entspricht. Wenn sich alle einig sind, großartig! Wenn nicht, muss sich das Team etwas Zeit nehmen (aber nicht zu viel, nur einige Minuten), um der Ursache für die abweichenden Schätzungen auf den Grund zu gehen. Bedenke dabei aber, dass die Schätzung eine eher allgemein gehaltene Aktivität ist. Sollte sich das Team zu sehr in Einzelheiten verzetteln, einmal tief durchatmen und die Diskussion wieder auf ein allgemeineres Niveau bringen.

Möchtest du das Ganze mal ausprobieren?

Intelligenter statt strenger schätzen

Eine einzelne Aufgabe sollte nicht mehr als 16 Stunden Arbeit in Anspruch nehmen. (Bei Verwendung von Story Points kannst du entscheiden, dass, sagen wir, 20 Punkte die Obergrenze sind.) Wenn einzelne Aufgabenelemente umfangreicher als das sind, lassen sie sich nur schwer zuverlässig abschätzen. Und Zuverlässigkeit ist vor allem für Elemente im oberen Bereich des Backlogs wichtig. Wenn für eine Aufgabe ein höherer Aufwand als der 16-Stunden-Schwellenwert (oder mehr als 20 Punkte) geschätzt wird, ist das ein Signal, diese Aufgabe weiter zu unterteilen und dann die Unteraufgaben erneut abzuschätzen.

Für Elemente, die sich im unteren Bereich des Backlogs befinden, reicht eine grobe Schätzung aus. Bis das Team die Arbeit an diesen Aufgaben tatsächlich beginnt, haben sich die Anforderungen möglicherweise geändert und auch deine Anwendung ist nicht mehr die alte. Frühere Schätzungen werden also nicht sehr präzise sein. Verschwende keine Zeit damit, Aufgaben zu schätzen, die sich mit hoher Wahrscheinlichkeit verschieben werden. Gib dem Product Owner einfach eine grobe Einschätzung, die er für eine entsprechende Priorisierung der Produkt-Roadmap verwenden kann.

Aus früheren Schätzungen lernen

Retrospektiven dienen dem Team dazu, Erkenntnisse aus früheren Iterationen zu gewinnen – darunter auch die Genauigkeit vorheriger Einschätzungen. Viele Agile-Tools wie Jira Software verfolgen Story Points, durch die das Überdenken und Neujustieren von Einschätzungen deutlich einfacher wird. Ziehe doch zum Beispiel einmal die letzten fünf vom Team bereitgestellten User Storys mit dem Story-Point-Wert 8 heran. Besprich mit dem Team, ob alle Aufgabenelemente dieselbe Mühe gekostet haben. Ist dies nicht der Fall, besprecht die Gründe dafür. Berücksichtigt diese Erkenntnis bei zukünftigen Besprechungen zu Einschätzungen.

Wie bei allen Komponenten agiler Verfahren ist die Schätzung eine Sache der Übung. Du wirst mit der Zeit immer besser werden.

Weiter geht's
Metrics