Schätzung ist schwer. Für Softwareentwickler ist sie einer der schwierigsten – wenn nicht gar der schwierigste – Aspekt des Jobs. Es müssen verschiedene Faktoren in Betracht gezogen werden, die Product Owner 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 aus sind, ihre Schäfchen ins Trockene zu bringen. Aber das ist ein Fehler. Die Schätzung 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 Schätzungen ansehen.  

Zusammenarbeit mit dem Product Owner

In der agilen Entwicklung ist der Product Owner 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. Product Owner erfassen die Anforderungen des Unternehmens, verstehen aber nicht immer die Details der Implementierung. Mit einer guten Schätzung kann der Product Owner 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 Product Owner kann durch das Aufteilen von Aufgabenelementen in granulare Unterelemente und Schätzungen einfacher Prioritäten für alle (auch potenziell versteckte!) Arbeitsbereiche festlegen. Oft ordnet der Product Owner 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 unterschiedliche 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 in einem Vakuum erstellten Schätzungen zu leiden hat. 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.

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. 

Halte Schätzungen allgemein. Sollte sich das Team zu sehr in Einzelheiten verzetteln, einmal tief durchatmen und die Diskussion wieder auf ein allgemeineres Niveau bringen. #AgileTipps

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, Einblicke aus früheren Iterationen zu gewinnen – darunter auch die Genauigkeit voriger 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ücksichtige diesen Einblick 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. 

Dargestelltes Produkt
Jira Software-Logo
Projekt- und Vorgangsnachverfolgung