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 von Story Points 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.
Das Schätzen von Agile Story Points 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!
Möchtest du Story Points einmal selbst ausprobieren? Registriere dich zuerst oder logge dich bei Jira ein.
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. Story Points sind Maßeinheiten für die Schätzung des Gesamtaufwands, der für die vollständige Implementierung eines Produkt-Backlog-Elements oder eines anderen Aufgabenelements erforderlich ist. Teams weisen Story Points relativ zur Aufgabenkomplexität, zum Arbeitsaufwand und zu Risiken oder Unsicherheiten zu. Für den besseren Umgang mit Unsicherheiten werden dabei Werte zugewiesen, um Aufgaben effektiver in kleinere Teile zu zerlegen. Teams erfahren dadurch nach und nach, wie viel sie in einem bestimmten Zeitraum erreichen können. Außerdem werden der Konsens und das Engagement hinsichtlich der Lösung verbessert. Auch wenn es nicht sehr intuitiv wirkt, hilft dieses Verfahren Teams dabei, schwierigere Entscheidungen zur Komplexität von Aufgaben zu treffen. Es gibt mehrere Gründe für die Verwendung von Story Points:
- 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.
Leider werden Story Points oft falsch eingesetzt. Dies ist zum Beispiel der Fall, wenn sie zur Beurteilung von Menschen oder zur Zuweisung detaillierter Zeitleisten und Ressourcen eingesetzt oder als Produktivitätsmesswert missverstanden werden. Teams sollten Story Points vielmehr verwenden, um den Aufgabenumfang und die Aufgabenpriorisierung besser einzuschätzen. Ausführliche Informationen zu Story Points und Schätzungsverfahren erhältst du in dieser Diskussionsrunde mit Branchenexperten. Oder lies einfach weiter, um Tipps zu agilen Schätzungen zu erhalten.
Story Points und Planning Poker
Teams, die mit Story Points beginnen, spielen oft Planungs-Poker. Bei Atlassian wird Planungs-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, atmet einmal tief durch und bringt die Diskussion wieder auf ein allgemeineres Niveau.
Möchtest du das Ganze mal ausprobieren?
- Installiere diese Planning Poker-App
- Informiere dich über Planning Poker
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 – beispielsweise auch zur Genauigkeit vorheriger Einschätzungen. Viele agile Tools wie Jira 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 gleich viel 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.
Related resources
