Direkt zum Hauptbereich

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.

Kommentare

Beliebte Posts aus diesem Blog

Das neue Outlook - One Outlook - erster Eindruck

Microsoft hat ein Problem: Outlook ist nicht gleich Outlook. Da ist das gute alte Outlook in der Desktop-Version. Das ist das, womit fast alle von uns im Alltag arbeiten und worüber ich hier schon oft berichtet habe. Outlook auf dem MAC sieht aber anders aus. Outlook auf Mobilgeräten sowieso. Dann gibt's noch Outlook im Web. Kein Wunder, dass Microsoft das alles entwirren, verschlanken und vereinheitlichen möchte. Gelingt es? Hier die interessantesten Funktionen des neuen Outlooks . 

Und jetzt alle zusammen! Teams - OneNote - Aufgaben - To Do

Ein Meeting jagt das nächste. Sich da nicht zu verzetteln, wird  im Zeitalter virtueller Besprechungen  noch anspruchsvoller. Kein Wunder, dass  im Zusammenhang mit Microsoft 365  zwei Fragen besonders häufig auftauchen: Wie dokumentiert man Besprechungen gut? Was hilft, offene Aufgaben nachzuhalten? Eine gute Lösung: Das in MS Teams integrierte OneNote-Notizbuch als gemeinsame Plattform auch für den Aufgabenüberblick zu nutzen.

Kategorien in Outlook - für das Team nutzen

Kennen Sie die Kategorien in Outlook? Nutzen Sie diese? Wenn ja wofür? Wenn ich diese Fragen im Seminar stelle, sehe ich oft hochgezogene Augenbrauen. Kaum jemand weiß, was man eigentlich mit diesen Kategorien machen kann und wofür sie nützlich sind. Dieser Blogartikel stellt sie Ihnen vor.

Microsoft Teams: Die neuen Besprechungsnotizen - Loop-Komponenten

  Haben Sie in letzter Zeit in einer Teams-Besprechung die Notizen geöffnet? Dort sind inzwischen die Loop-Komponenten hinterlegt. Die sind zwar etwas nützlicher als das, was zuvor zur Verfügung stand. Trotzdem ist noch Luft nach oben. Und es gibt sogar einige ernstzunehmende Stolperfallen. Hier ein erster, kritischer Blick auf das was Sie damit tun können. Und auch darauf, was Sie besser sein lassen.

E-Mail-Vorlagen gemeinsam nutzen (Outlook)

Mittlerweile wird praktisch alle Routine-Korrespondenz in Outlook erledigt. Was liegt da näher, als ein gutes Set von Vorlagen zu erstellen und diese gemeinsam in Team zu nutzen? Leider hat Microsoft vor diesen – an sich simplen – Wunsch einige Hürden gebaut.

Das Ubongo Flow Game

Spiele bieten eine gute Gelegenheit, zeitliche Erfahrungen zu verdichten und gemeinsam zu lernen. Karl Scotland und Sallyann Freudenberg haben im Mai 2014 das Lego Flow Game veröffentlicht. Wir haben die Spielidee übernommen, aber das Spielmaterial gewechselt. Statt Legosteinen benutzen wir Material aus Grzegorz Rejchtmans Ubongo-Spiel. Hier präsentieren wir die Anleitung für das Ubongo Flow Game.

Outlook-Aufgabenliste: bitte nicht die Aufgaben des ganzen Teams!

Am Tag der Arbeit kommt eine Lösung, nach der ich schon so oft gefragt wurde: Wie schaffe ich es, dass meine Outlook-Aufgabenliste nur meine eigenen Aufgaben anzeigt und nicht auch die E-Mails, die meine Kollegen gekennzeichnet haben oder Aufgaben, die einfach in einem gemeinsamen Postfach stehen?

Nie wieder Ärger mit Besprechungsserien in Outlook

Erstellen auch Sie Besprechungsserien in Outlook? Ärgern auch Sie sich manchmal darüber, wenn Sie etwas zu ändern haben? Falls nicht, versenden Sie entweder keine wiederkehrenden Outlook-Besprechungen (Serienterminen). Oder Sie ändern nie etwas daran. Dann ist dieser Artikel nichts für Sie. Lesen Sie aber bitte weiter, falls Sie sich schon immer mal gefragt haben, ob es eine Lösung gibt? 

"Denn sie wissen nicht was sie tun ...! Freigeben und teilen in OneDrive und SharePoint und per E-Mail

Neuerdings können Sie bei Ihren E-Mails entscheiden, ob Sie den Anhang als Datei (Kopie) anhängen wollen oder einen Link senden. Doch was kann dieser Link? Wie sicher ist er? Wer kann was damit tun? Lesen Sie hier was sinnvoll ist und was weniger.