Keine Einschätzungen des Sprint Backlogs mit Task Points

Als ich 2005 das Buch Agile Estimating and Planning schrieb, hatte ich mich bereits seit fünf Jahren mit verschiedenen Einschätzungsmethoden beschäftigt. Nachdem ich mit einigen Teams – besonders mit denen, die direkt für mich arbeiteten – Experimente dazu durchgeführt hatte, hatte ich das Gefühl, genug darüber gelernt zu haben, um das Buch schreiben zu können.

Allerdings gab es noch so einiges, was ich nicht wusste (und natürlich jetzt auch noch!). Daher suchte ich nach Teams, die ihre Projekte anders einschätzten und planten als ich es tat. Einige dieser Teams benutzten zusätzlich zu Story Points auch Task Points für die Einschätzung ihrer Product Backlog Items.

Das fand ich interessant. Damals war ich bereits ein Befürworter von Story Points – und mittlerweile bin ich aufgrund der Vorteile von Story Points ein noch größerer Fan geworden. Ich konnte jedoch einfach nicht nachvollziehen, warum ein Team Task Points nutzen sollte. Da ich aber ein so großer Fan von Story Points war, wollte ich einfach mehr über die Teams herausfinden, die mit Task Points arbeiteten.

Ich konnte ein paar Teams überreden, mich ihnen dabei zuschauen zu lassen, um auf diese Weise mehr darüber erfahren zu können.

Was ich dabei herausfand, bestätigte meine Annahme, dass Teams ihre Sprint Backlog Items nicht mit Task Points bewerten sollten.

Der Hauptvorteil von Story Points

Der Hauptvorteil von Story Points ist, dass Personen mit den verschiedensten Fähigkeiten, Leveln an Erfahrung und unterschiedlichem Hintergrund gemeinsam eine Einschätzung für ihre Arbeit abgeben können.

Nehmen wir ein nicht ganz ernst gemeintes Beispiel und stellen uns vor, ich würde gemeinsam mit einem Oktopus einschätzen wollen, wie viel Aufwand es wäre, mein Auto zu waschen.

Ein Oktopus hat viermal so viele Arme wie ich. Also müsste der Oktopus mein Auto auch viermal schneller waschen können als ich. (Ich habe ja gesagt, dass das kein ganz ernst zu nehmendes Beispiel ist. Aber warten Sie ab.)

Der Oktopus wird aber auch jedes andere Auto viermal schneller waschen können als ich. Der Oktopus und ich können uns also vielleicht darauf einigen, dass mein kleiner Zweisitzer etwa fünf Story Points bekommt und ein etwas größeres Auto zehn Punkte bekommt.

Die Story Points erlauben es dem Oktopus und mir also, uns gemeinsam auf eine gewisse Anzahl an Punkten zu einigen – auch wenn der Oktopus sicherlich wesentlich schneller ist als ich.

Task Points

Bei den Teams, die ich beobachtete, fiel mir auf, dass ein Task Point fast das Gleiche war wie ein Story Point. Alle Teams, mit denen ich sprach, wollten jedoch eine kleinere Einheit als Story Points benutzen.

Beispielsweise könnte ein Team, das zehn Story Points pro Sprint erledigt, etwa 80 Task Points pro Sprint schaffen.

Die Teams wollten einfach eine kleinere und feinere Einheit, um besser ihren Fortschritt verfolgen zu können. Es ist so ähnlich, wie wenn der Tacho im Auto die Geschwindigkeit in Lichtjahren pro Stunde angeben würde. Auf diese Weise würde ich nur schwer feststellen können, ob ich mich an das Tempolimit halte oder nicht.

Feinere Einheiten zu benutzen, war für viele Teams eine gute Idee. Immerhin ist es ziemlich schwer, mit Story Points den täglichen Fortschritt eines Teams zu messen, das beispielsweise sieben Story Points in zwei Wochen schafft. In diesem Fall sind Story Points einfach eine zu große Einheit, um hilfreich zu sein.

Was ist mit Stunden?

Es gibt aber schon eine feinere Einheit, mit der jedes Teammitglied ohnehin schon vertraut ist: Stunden.

Als ich die Teams beim Einschätzen mit Task Points beobachtete, fiel mir auf, dass dies keinen Vorteil verglichen mit der Einschätzung von Sprint Backlog Items in Stunden hat.

Es gibt einen grundlegenden Unterschied zwischen Product Backlog Items (meist in Form von User Stories) und Sprint Backlog Tasks: An einem Product Backlog Item arbeiten in der Regel drei bis fünf Leute; vielleicht ein oder zwei Programmierer, ein Tester und eventuell ein Designer, Architekt, Analyst oder technischer Redakteur etc. An einem Task arbeitet normalerweise nur eine einzige Person.

Das bedeutet, dass nicht alle Mitglieder eines Teams gemeinsam eine Einschätzung für einen Task abgeben müssen, so wie es bei einem Product Backlog Item der Fall wäre. Jeder im Team hat zwar die Möglichkeit, eine Einschätzung für den Task abzugeben, aber nur derjenige, der am Ende an dem Task arbeitet, kann die endgültige Einschätzung vornehmen.

Wenn höchstwahrscheinlich nur eine bestimmte Person an einem Task arbeiten wird, dann sollte man auch die Einschätzung dieser Person für die Aufgabe nehmen. Wenn zwei oder drei Personen an einem Task arbeiten werden, lässt man entweder alle drei gemeinsam eine Einschätzung abgeben oder nimmt die Einschätzung der Person, die am ehesten die Arbeit erledigen wird.

Wenn die Arbeit während des Sprints an eine andere Person abgegeben wird, werden sich die Einschätzungen im schlimmsten Fall einfach ändern. Wenn ein schnelleres Teammitglied die Arbeit eines langsameren Kollegen übernimmt, ändert er die Einschätzung von acht auf vier Punkte – oder umgekehrt.

Warum keine Task Points?

Task Points haben also gegenüber Stunden keine Vorteile. Sie haben allerdings Nachteile gegenüber Story Points:
- Viele Teammitglieder sind nicht damit vertraut.
- Es besteht die Notwendigkeit von Basiswerten, damit überhaupt Einschätzungen getroffen werden können.
- Es besteht das Risiko, dass die Einschätzungen sich mit der Zeit nicht mehr an den ursprünglichen Basiswerten orientieren.

Mein Tipp zum Umgang mit Task Points

Ich beendete meinen Exkurs in die Welt der Task Points, ohne dass man mich von ihrem Wert überzeugen konnte. Ich bin weiterhin ein Befürworter von commitment-orientiertem Sprint Planning, so wie wir es kennen. Vielleicht ist kapazitätsorientiertes Sprint Planning eine bessere Bezeichnung dafür. Meines Erachtens hat es erhebiche Vorteile gegenüber velocity-orientiertem Sprint Planning.

Bei den meisten Teams funktioniert commitment- oder kapazitätsorientiertes Sprint Planning mit Stunden am besten. Einige Teams folgen diesem Prozess, lassen aber die Einschätzungen weg und nutzen diese nur in Meetings, um herauszufinden, was sie in den Sprint aufnehmen können.

Andere Teams schätzen die Sprint Backlog Items einfach gar nicht ein. Jeder dieser Ansätze kann gut funktionieren, wenn ein Team erst einmal Erfahrung damit gesammelt hat.

Ich bin froh, dass ich dieses Projekt durchgeführt habe, um mehr über Task Points und die Teams, die sie benutzen, herauszufinden.

Wenn ich mir alternative Methoden für das Einschätzen anschaue, bin ich immer etwas enttäuscht, wenn ein neuer Ansatz nicht besser ist als ein bestehender. Aber das ist leider recht häufig der Fall.

Und doch werden wir die kontinuierlichen Verbesserungen finden, nach denen jeder Agilist strebt, wenn wir so viele unterschiedliche Optionen wie möglich betrachten.

Dieser Text stammt aus dem Blog von Mike Cohn und wurde von uns ins Deutsche übersetzt. 

Product Owner: Aufgaben & Herausforderungen

=> Finde heraus, was ein Product Owner den ganzen Tag so macht.

Was ist eine Scrum Story?

=> Hier findest du die Unterschiede zwischen User Stories, Epics und Themes heraus.

Certified Scrum Product Owner Training

=> Werde zertifizierter Product Owner mit unseren CSPO Trainings.