Agiles Schätzen im Projekt
„Wieviel schaffen wir in diesem Sprint?“ „Ist die Story zu groß oder zu komplex?“ „Haben wir uns zu viel vorgenommen? Oder nicht genug? Was ist zu viel?“ „Sollen wir die Story noch mit aufnehmen, oder besser doch nicht?“ Solche Fragen und Unsicherheiten tauchen bei der Sprintplanung oder beim Versuch die User Stories agil zu schätzen.
Im Folgenden geht es also genau darum – um agiles Schätzen. Wer schätzt? Was wird geschätzt und wieso überhaupt? Welche Methoden gibt es? Wie geht man damit um, wenn man sich völlig verschätzt hat?
Wieso überhaupt agil schätzen?
Auch wenn es vielleicht Übung braucht und zu Anfang etwas Zeit erfordert, bringt richtiges agiles Schätzen sehr viel Sicherheit ins Team.
Zum einen liefert es Planungssicherheit. Durch gutes Schätzen lernt das Team, die eigenen Kapazitäten abzuschätzen. Das Team lernt zu schätzen, wie groß zum Beispiel die Tickets oder User Stories sein sollten damit sie abgearbeitet werden können. Es lernt, wann ein Ticket zu groß ist. Wenn wir den Sprint gänzlich ohne zu Schätzen planen, und am Ende viele Stories unbearbeitet oder unerledigt lassen, kann das unter Umständen für viel Frustration sorgen. Diese Frustration entsteht im Team, aber auch bei den Stakeholdern. Agiles Schätzen lernen kann das Team demnach in eine Position versetzen immer zuverlässiger und genauer angeben zu können wie viele Stories im jeweiligen Sprint abgearbeitet werden können.
Und das führt direkt zum nächsten Punkt, wieso richtiges Schätzen für Sicherheit im Team sorgt. Richtiges agiles Schätzen schafft Vertrauen. Das Vertrauen wächst, da das Team gelernt hat, seine gemeinsame Leistungsfähigkeit richtig einzuschätzen und den Sprint frustfrei, weil ohne liegengebliebene Tickets, abzuschließen. Das Team entwickelt Vertrauen in seine eigene Arbeit . Gleichzeitig wächst dadurch auch das Vertrauen, das die Stakeholder dem Team entgegenbringen. Liefert das Team wie angekündigt, steigert das die Unternehmensgesundheit überhaupt.
Wer schätzt was, wenn wir agil Schätzen?
Aber wer übernimmt eigentlich das Schätzen im Team? Schätze ich meinen eigenen Arbeitsaufwand ein oder ist das eine Aufgabe des Product Owners? Und was wird überhaupt agil geschätzt, der Aufwand jedes einzelnen Tickets, jeder Task, jede Sub-Task?
Die Antwort auf die Frage „wer?“ ist einfach. Das Team schätzt gemeinsam. Denn am Ende des Sprint Plannings ist es auch das Team, das sich gemeinsam verpflichtet die Agilen Schätzungen zu erfüllen. Wir schätzen auf der Ebene der User Stories, nicht auf der Ebene der einzelnen, dazugehörigen Tasks. So vermeiden wir zu feingliedrig in die Schätzung hineinzugehen.
Von Storypoints zu Obstsalat – wie wir agil schätzen.
Jetzt wissen wir, welchen Sinn das agile Schätzen hat. Wir haben auch die Fragen nach dem „wer?“ und dem was geschätzt wird geklärt. Doch eine entscheidende Frage bleibt: Wie schätzen wir?
Ganz klassisch kann in in absoluten Werten geschätzt werden. Wir können zum Beispiel in Personentagen oder Stunden schätzen. Das hat auf den ersten Blick den Vorteil, dass scheinbar jeder ein Gefühl dafür hat, wie lang eine Stunde ist. Vor allem wohlorganisierte Teams haben für die Erledigungsdauer vieler Aufgaben klare Vorgaben. Den meisten Menschen jedoch fällt es sehr schwer, absolute Dinge zu schätzen. Das schließt auch die Abschätzung der Zeit mit ein. Sind die zu schätzenden Stories zudem sehr komplex, ist die agile Schätzung zum Scheitern verurteilt.
Man hat also angefangen User Stories in abstrakter(er) Art und Weise zu schätzen. Wir schätzen dann zum Beispiel anhand von Storypoints. Mit ein wenig Übung fällt den Teams das abstraktere agile Schätzen so oft leichter. Darüber hinaus bietet es den Entwicklern auch einen gewissen „Selbstschutz“, da sie so keine präzisen Stundenzusagen machen müssen. Agile Schätzen wird oft abgelehnt, da wir uns fürchten auf unsere Schätzungen festgenagelt zu werden. Aber wie schätzt man mit Storypoints?
Eine gute Grundlage für das Schätzen mit Storypoints ist eine abgewandelte Fibonacci-Folge (nähere Informationen zur eigentlichen Fibonacci-Folge finden sich hier: Wikipedia). Die zum Schätzen abgewandelte Zahlenreihe besteht meist aus den Punkten 1, 2, 3, 5, 8, 13, 20. Sie kann fortgeführt werden, es empfiehlt sich jedoch die 8, 13 oder 20 als größten Storypoint-Aufwand zu definieren.
Hat sich das Team auf die genannten Grundlagen commited, kann es zwei verschiedenen Ansätzen folgen:
1) Agiles Storypointschätzen auf Grundlage von Zeitintervallen
Ein Ansatz ist, Storypoints vor dem Hintergrund von Zeitintervallen festzulegen. Ein Ansatzpunkt dafür ist, dass wir festlegen, dass kein Ticket, keine Story, mehr als 10 % der Gesamtkapazität des Sprints einnimmt. Angenommen unser Sprint dauert zwei Wochen, also zehn Arbeitstage. Haben wir dann zum Beispiel ein Team von sechs Entwicklern, kommen wir auf insgesamt 60 Personentage. 10 % davon wären sechs Tage. Eine Story sollte also einen Arbeitsaufwand von circa sechs Personentagen nicht überschreiten. Wenn des Weiteren festgelegt wird, dass die größte Story maximal 13 Storypoints entsprechen darf, ergeben sich alle anderen Werte aus einem einfachen Dreisatz. Es ist nicht vorgesehen, dass Storypoints durch feste Zeitwerte ersetzt werden. Da sich aus dem Dreisatz also sehr krumme Werte, wie 1,85 oder 0,615 ergeben, wandeln wir diese wieder in „Personentag-Intervalle“ um:
2) Agiles Storypointschätzen auf Grundlage einer „Geschichte“, zum Beispiel mithilfe eines Obstsalates.
Sind die Teams sehr unsicher und müssen erst ein Gefühl fürs abstrakte agile Schätzen bekommen, kann man auch noch einen anderen, sehr intuitiven Weg gehen. Man stelle sich vor: Wir machen einen Obstsalat. Dieser Obstsalat besteht aus Apfel, Banane, Kiwi, Ananas, Weintraube, Mango, Erdbeere, Granatapfel und Walnuss. Wieviel Aufwand steckt in der Zubereitung der einzelnen Obstsorten für den Obstsalat? Auf Basis dieser Geschichte kann man ein Team sehr spielerisch an das agile Schätzen mit Storypoints heranführen.
Das Team schätzt den Aufwand der Zubereitung der einzelnen Obstsorten und bringt diese in eine Reihenfolge. Zuerst jeder für sich, in Runde 1. In Runde 2 diskutiert das Team dann die Einschätzungen und bringt sie auf einen Nenner. Generell könnte Einigkeit darüber bestehen, dass die Bearbeitung des Granatapfels die aufwendigste ist. Es werden aber Diskussionen aufkommen. Diese Diskussionen könnten beispielsweise um die Zubereitung von Weintrauben kreisen: ganz oder halbiert? Vielleicht doch in Scheiben – müssen die Kerne entfernt werden? Nehmen wir die abgepackte Walnuss aus der Tüte oder muss die Nuss noch geknackt werden? Das Vorgehen über eine Geschichte kann einem Team ein leichteres Gefühl und Verständnis für abstraktes agiles Schätzen beibringen. Denn so werden wir unabhängig von abstrakten Zeitintervallen und einigen uns spielerisch auf eigene interne Einheiten.
Es kann auch hilfreich sein, eine „Referenzstory“ anzugeben. Diese könnte beispielsweise lauten: „Eine Datenbankanpassung benötigt in der Regel fünf Storypoints.“ Tragen wir diese Referenzstories in die obige Tabelle ein, dienen sie dem Team so als Orientierungspunkt.
Mit solchen Zeitintervallen an der Hand entwickeln die Teams schneller ein Gefühl für Storypoints und abstraktes agiles Schätzen.
Am Beispiel des Obstsalats bietet sich noch die Möglichkeit eine „gesunde Durchmischung“ zu demonstrieren. Der Obstsalat soll ja nicht nur aus Himbeeren und der Sprint nicht nur aus kurzen Stories bestehen. Die Vorlieben des Teams entscheiden, ob und welche erweiterte Geschichte zum Einsatz kommt. Wir nutzen die Methode des Obstsalats zumeist, um ein allgemeines Gefühl für abstraktes agiles Schätzen zu gewinnen.
Neben Obstsalat bieten sich dafür aber auch beispielsweise T-Shirt-Größen (XS, S, M, L, XL, XXL) an.
Ist es denn überhaupt notwendig mit Storypoints zu schätzen? Eine Verwendung von Storypoints ist ratsam, wenn Ticketsysteme, wie beispielsweise Jira genutzt werden. Dort tragen wir in der Sprintplanung die für den Sprint geplanten Stories, incl. veranschlagter Storypoints ein. Schließen wir am Ende den Sprint, können wir in den Burndown-Charts gut darstellen wie/ob die Abarbeitung der Stories funktioniert hat – und folglich auch, ob wir gut geschätzt haben.
Wie sich die Retrospektiven für einen Blick aufs Schätzen eignen.
Am Ende des Sprints, in der Retrospektive betrachten wir die angelegten Burn-Down Charts. „Haben wir geschafft was wir uns vorgenommen haben?“ „Woran lag es, dass wir die agil geschätzten Storypoints nicht erreicht haben?“ Wichtig: diese Betrachtungen zielen nicht darauf, einzelne Entwickler zur Verantwortung zu ziehen. Die Schätzung, sowie die Leistung während des Sprints liegen in der Teamverantwortung. Generell sollten wir aber, gerade zu Beginn, die „Velocity“ betrachten. Die Velocity wird über mehrere Sprints als Durchschnitt realisierter Storypoints ermittelt und kann mit den geplanten Storypoints verglichen werden. Auf diese Weise treffen wir fundierte Aussagen. Dadurch und durch die Betrachtung der einzelnen Burndown-Charts der Sprints, erkennen wir wie erfolgreich das Team schätzen kann. Es sollte aber bedacht werden, dass die Velocity nur als Indikator dient und kein Garantiemaß darstellt.
Zeigt sich am Sprintende, vielleicht sogar wiederholt, dass beispielsweise 80 Punkte geschätzt, aber nur 65 Punkte erreicht wurden, stellen sich zentralen Fragen. „Wieso ist das so?“. Gab es „Impediments“, die nicht ausgeräumt wurden? Bugs? Oder hat sich das Team einfach verschätzt und braucht etwas mehr Übung? An dieser Stelle können und müssen diese Punkte diskutiert werden. Stories, die innerhalb des Sprints begonnen, aber nicht beendet wurden, können als „Spill-Over“ in den nächsten Sprint übertragen werden. Das sollte allerdings nicht zum Regelfall werden.
Agiles Schätzen bringt viele Vorteile für das Team und das Voranschreiten des Projekts mit sich. Auch wenn es zu Beginn ein wenig Übung und Selbstreflexion erfordert. Auf lange Sicht kann das richtige agile Schätzen einen großen Beitrag zur Planungssicherheit und zum Vertrauen innerhalb des Teams beitragen.
