Warum relatives Schätzen so schwer ist

Wenn wir Scrum vorstellen, weisen wir darauf hin wie wichtig und praktisch das relative Schätzen ist. Unsere Zuhörer nehmen dies zur Kenntnis, weil es plausibel klingt. Besonders das Burndown-Chart zur Fortschrittsverfolgung nach dem Schätzen kommt gut. Aber wenn wir Team über eine längere Zeit begleiten, stellen wir fest, dass die Teams erst spät mit dem relativen Schätzen anfangen. Könnte es sein, dass diese Technik zu schwierig ist? Ich habe da eine andere Vermutung.

Wie funktioniert relatives Schätzen?

Wir wissen, dass Schätzungen nur auf Zeitbasis nicht funktionieren. Wer mehr dazu erfahren will, kann bei der Wikipedia unter dem Stichwort Planungsfehlschluss anfangen zu suchen /1/.

Aber keine Schätzung ist keine Alternative. Die agile Community hat gute Erfahrungen mit relativem Schätzen gemacht. Dabei wird nicht die einzelne Aufgabe betrachtet, sondern mehrere Elemente. Diese Elemente werden in Beziehung gesetzt. Aufgabe A dauert länger als Aufgabe B aber nicht so viel wie C. D und E sind ungefähr so viel Arbeit wie B. F ist eher so wie A und für H müssen wir besser mehr Zeit einplanen. Darauf ergibt sich diese Einteilung:

• B, D, E
• A, F
• C
• H

Damit wir einfacher rechnen können, vergeben wir relative Aufwandspunkte (Story Points, /2/). Dafür können wir eine Quasi-Fibonacci-Folge verwenden. Das sind natürliche Zahlen, aber nicht alle und der Abstand zwischen den Zahlen wird nach außen hin größer. Viele natürliche Dinge folgen der Fibonacci-Folge. Im Beispiel könnten wir folgende Punkte vergeben:

• B, D, E: je 3 Story Points
• A, F: je 5 Story Points
• C: 8 Story Points
• H: 13 Story Points
• Summe im Arbeitsvorrat: (3x3) + (5x2) + 8 + 13 = 40 Story Points

Dann verfolge ich einfach, wie viele Story Points das Team in einem Sprint schafft (Velocity).

Soweit die Theorie. Sehen wir uns mal die Gründe an, warum Teams diese Schätztechnik nicht benutzen.

Bei uns ist aber ganz anders

Natürlich ist alles in jedem Team anders:

• "Wie können wir im Team schätzen, wenn wir gar kein Team sind. Ich kann gar nichts zu einer bestimmten Story sagen, weil ich sie inhaltlich nicht bewerten kann. Wenn Alice sagt, das seien 8 Punkte für sie, dann ist es halt so."
• "Ist doch klar, dass die erfahren Kolleginnen und Kollegen immer weniger Story Points vergeben. Die sind ja auch schneller fertig. Wozu müssen wir das im Team besprechen?"
• "Wir haben viele Fehler im System, die wir beheben müssen. Das kann man nicht schätzen. Mal ist man nach 5 Minuten fertig, mal nach 5 Tagen noch nicht."
• "Wozu braucht ihr Story Points? Am Ende rechnet ihr ja doch wieder in Personentage oder Stunden um. Dann können wir doch auch gleich in Zeit schätzen."

Ich lasse diese Einsprüche zu, weil ich nicht den Eindruck habe, dass sich jemand rausreden will. Das Thema ist ein anderes.

Unsere Weltsicht passt nicht

Ich möchte mit einer kleinen Übung von Dave Logan kurz abschweifen. Sehen Sie sich um und merken Sie sich alle grünen Dinge im Raum. Prägen Sie sich wirklich alle grünen Dinge ein. Schließen Sie nun Ihre Augen. Zählen Sie alle Dinge im Raum auf, die blau sind.

Sie werden sicher sagen, dass dies unfair sei. Ich habe doch vorher nach grünen Dingen gefragt. Stimmt. Aber ich habe nicht gesagt, dass Sie alle blauen Dinge übersehen sollen. Sie waren so mit den grünen Dingen beschäftigt, dass Sie die blauen Dinge gar nicht wahrgenommen haben.

Wir haben eine selektive Wahrnehmung. Wir achten auf das, was uns wichtig ist. Wir achten auf etwas, weil es für uns relevant ist. Meine Vermutung ist, dass Teams dann Schwierigkeiten mit dem relativen Schätzen haben, wenn sie eine andere Erwartung haben. Wenn meine Grundfrage "Wie lange brauche ich für diese eine Aufgabe?" ist, dann erwarte ich eine Zeitangabe. Dann spielt es keine Rolle, ob ich in Tagen, Minuten oder Story Points antworte.

Story Points ist keine Zeitangabe. Story Points sind ein Maß für Arbeit.

Es gibt ein gutes Buch über Aufwandsschätzungen in Softwareprojekten von Steve McConnell /3/. Darin schreibt der Autor, dass es beim Schätzen darum geht, zählbare Dinge zu finden und zu vergleichen. Wenn ich in einem Projekt 100 Berichte in einer bestimmten Zeit erstellt habe, brauche ich in einem anderen Projekt wahrscheinlich die doppelte Zeit, wenn dort 200 Berichte mit vergleichbarer Komplexität bei ähnlichen Rahmenbedingungen zu erstellen sind.

Was sind also zählbare Dinge in Ihrem Projekt? Wenn wir irgendwas finden können, das wir zählen können, wird das Schätzen einfacher.

Nun sagen viele Teams, dass es ihnen schwer fällt, zählbare Dinge zu finden. Vielleicht ist der Lösungsansatz noch nicht klar. Dann weiß man noch nicht, was zählenswert ist. Oder die Anforderungen sind sehr unterschiedlich. Dann gibt es auch wenig Gemeinsamkeiten.

Nun kommen die Story Points ins Spiel. Sie sind nämlich keine Zeiteinheit, sondern ein Maß für Arbeit. Sie sollen Zählbarkeit herstellen.

Wie nutzt man Story Points dann genau?

Was schätzen Sie, wie lange ich brauche, um nach Hause zu kommen? Diese Frage können Sie nicht beantworten, weil Sie nicht wissen, wie weit mein Zuhause entfernt ist. Zunächst brauchen wir die Entfernung in km. Dann wählen wir ein Verkehrsmittel aus und betrachten Wetter und Verkehrslage. Erst danach können wir die Zeit abschätzen. Die Kilometerzahl ist unser Maß für Arbeit.

Ein Autofahrer ist schneller als ein Radfahrer. Trotzdem ist es die gleiche Strecke. Wenn wir unterwegs sind, können wir messen, wie viele Kilometer wir in einer bestimmten Zeit schaffen (km/h).

In dieser Art nutzen wir auch die Story Points. Wir ermitteln die Arbeitsmenge. Das ist die Summe der Story Points, die wir uns für einen Sprint vorgenommen haben. Dann zählen wir, wie viele Story Points wir im Sprint tatsächlich geschafft haben. Doch ein Element fehlt noch.

Wir müssen trotzdem mit der Zeit vergleichen

Gerade wenn Teammitglieder häufig wechseln oder sie nur zum Teil im Scrum-Team arbeiten, reicht es nicht aus, nur die Story Points zu zählen. Wir müssen auch immer die geplante und tatsächliche Nettokapazität der einzelnen Teammitglieder in Betracht ziehen.

In Abbildung 1 sehen wir die Nettokapazität eines Teams in zwei Sprints. Sprint 10 ist abgeschlossen. Die Ist-Verfügbarkeit entspricht auch ungefähr der Planung. In Sprint 10 hat das Team eine Arbeitsmenge von 13 Story Points geschafft.

Im anstehenden Sprint 11 ist Bob im Urlaub und Charly muss zur Hälfte in einem anderen Team mitaushelfen. Welche Arbeitsmenge sollte sich das Team vornehmen? Mit Story Points haben wir etwas Zählbares.

Abb. 1: Nettokapazität in 2 Sprints

Bei einer Velocity von 13 Story Points und 132 Stunden Arbeitszeit, schafft das Team wahrscheinlich nur 8 Story Points, wenn es nur 80 Stunden zur Verfügung hat (13/132x80).

Jetzt ist die Schätzung eine Planungshilfe. Fassen wir die wichtigsten Punkte zusammen.

Zusammenfassung

Schätzen ist eine Planungshilfe:

• Schätzen bedeutet, zählbare Dinge finden und zu vergleichen.
• Story Points sind ein Maß für Arbeit und keine Zeiteinheit.
• Story Points entstehen durch den Vergleich von mehreren Anforderungen. Alle bekannten Anforderungen werden in Beziehung gesetzt.
• Um einfacher rechnen zu können, vergeben wir Aufwandspunkte aus der Fibonacci-Folge.
• Damit die Anforderungen vergleichbar sind, brauchen wir feststehende Referenzen, die über die ganze Zeit nicht geändert werden.
• Wir zählen, wie viele Story Points wir pro Sprint schaffen. Diese Menge wird in Relation zur Nettokapazität des Teams gestellt.
• Die Anforderungen werden als Teilziele oder Ergebnisse und nicht als To-Do bewertet.
• Wir bewerten aus Teamsicht.

Was bedeutet das für die Planung?

• Neue Anforderungen werden immer im Rahmen des Refinements geschätzt, und zwar durch Vergleich mit den bestehenden Referenzen.
• Zu Beginn der Sprintplanung erfasst der Scrum Master oder jemand anders die Nettokapazität des Teams. Wer ist wie viele Stunden da?
• Im Review werden die Story Points der erledigten Anforderungen aufsummiert. Es wird überprüft, wie viele Stunden das Team tatsächlich in Summe im Sprint gearbeitet hat.

Anmerkungen

• /1/ Jeff Sutherland hat auf seiner Webseite Research zusammengetragen, warum das mit den Zeitschätzungen so unzuverlässig ist. Neben dem Artikel sind auch die Fragen und Antworten in den Kommentaren interessant. Siehe Jeff Sutherland: "Story Points: Why are they better than hours?", Scrum Inc. Blog, erschienen am 16. Mai 2013, abrufbar unter https://www.scruminc.com/story-points-why-are-they-better-than/ 
• /2/ Ich bin mir nicht sicher, wer den Begriff "Story Point" zuerst benutzt oder veröffentlicht hat. Eine erste Google-Suche listet Ron Jeffries auf.
• /3/ McConnell, Steve: Software Estimation : Demystifying the Black Art. München: Microsoft Press, 2006.; Deutsche Ausgabe: McConnell, Steve: Aufwandschätzung für Softwareprojekte. München: Microsoft Press, 2006.