Relative Schätzung
Die relative Schätzung gibt einem Backlog-Item eine Grösse, indem sie es mit Items vergleicht, die bereits eine haben, auf einer Skala einheitenloser Zahlen, den Story Points. Ein Item mit 5 gilt als rund fünf Drittel eines Items mit 3. Die Zahl enthält keine Dauer. Die Agile Extension zum BABOK Guide beschreibt die Schätzung im agilen Umfeld: Die Grössen werden Iteration für Iteration überarbeitet und treffen umso genauer, je besser das Team seine eigene Kapazität und die Art der Arbeit kennt. Die in einer Iteration fertiggestellten Punkte ergeben zusammen die Velocity des Teams. Die Punkte gehören dem Team, das sie vergeben hat, und lassen sich nicht von Team zu Team vergleichen.
Ziel
Die relative Schätzung bemisst und ordnet ein Backlog, ohne von Anfang an Stunden oder Franken anzusetzen. Die Agile Extension nennt drei Verwendungen: Kosten und Aufwand eines Arbeitspakets bestimmen, die Prioritäten der Initiative festlegen, sich auf einen Termin verpflichten. Der Leitfaden stellt die Schätzungen ausserhalb der ausgelieferten Lösung: Sie dienen den internen Entscheidungen des Teams und seiner Auftraggeber.
Das Ergebnis der Technik ist ein Backlog, in dem jedes Item eine Grösse auf einer gemeinsamen Skala trägt, dazu die über die vorangegangenen Iterationen erhobene Velocity. Beides zusammen beantwortet die Frage eines Lenkungsausschusses: wie viele Iterationen für diesen Umfang.
Platz in der Familie der Schätzverfahren
Die Schätzung im allgemeinen Sinn umfasst die Verfahren, die eine Menge in einer echten Einheit liefern, eine Dauer, Kosten oder einen Aufwand, sei es als Bandbreite. Die relative Schätzung liefert einen Rang auf einer dimensionslosen Skala. Die Menge entsteht erst danach, wenn die Velocity des Teams eine Punktsumme in eine Anzahl Iterationen umrechnet und diese Anzahl anschliessend zu den erhobenen Kosten einer Iteration in Franken. Die Agile Extension baut auf der allgemeinen Technik auf und beschreibt deren Anpassung an das agile Umfeld.
Ein Aufwand in Personentagen lässt sich zwischen Teams vergleichen, über Projekte hinweg summieren und in einem Vertrag festhalten. Ein einheitenloser Rang taugt für einen einzigen Zweck, die Reihenfolge eines Backlogs durch ein bestimmtes Team, und die meisten Fehler entstehen daraus, dass man ihm die drei anderen abverlangt.
Einsatz
Wann einsetzen
- Ein Backlog, das vor einer Zusage zu ordnen ist: Der Vergleich der Items untereinander genügt, um die Lieferreihenfolge zu bestimmen.
- Ein stabiles Team, das in Iterationen liefert: Die erhobene Velocity übersetzt die Punkte in eine Anzahl Iterationen.
- Noch unscharf definierte Items: Die Unsicherheit geht in die Grösse ein, ohne dass das Item in Aufgaben zerlegt werden muss.
- Abwägung zwischen den Initiativen eines Portfolios: das Ausmass der Kandidaten einordnen, bevor eine detaillierte Kostenstudie angestossen wird.
- Beginn einer Iteration: Jedes Item erhält seine Grösse in der Sitzung, ohne individuelle Vorarbeit.
Wann nicht einsetzen
- Vertragliche Zusage in Stunden oder Franken: direkt beziffern, per Bottom-up-Schätzung oder parametrischer Schätzung.
- Ein bei jeder Iteration neu zusammengesetztes Team: Die Velocity hat keine Vergleichsbasis, also zerlegen und in Zeiteinheiten beziffern.
Beschreibung
Was die Zahl misst
Die Agile Extension stützt die Grösse einer User Story auf fünf Faktoren, die die Sitzung Item für Item durchgeht. Das Wissen: Über welche Informationen verfügt das Team zu diesem Item. Die Erfahrung: Hat es das oder etwas Ähnliches schon gemacht. Die Komplexität: Wie schwierig ist die Umsetzung. Die Grösse: Wie viel Arbeit verlangt das Item. Die Unsicherheit: Welche Variablen und unbekannten Faktoren können es stören.
Ein einziger dieser Faktoren genügt, um ein Item an das obere Ende der Skala zu setzen. Eine Arbeit von zwei Tagen, bei der niemand das Verhalten des angrenzenden Systems kennt, wird höher bewertet als eine Arbeit von einer Woche, die das Team bereits dreimal durchgeführt hat. Die Zahl fasst eine Menge Arbeit und ein Mass an Unkenntnis zusammen.
Die Skala und die Referenz-Story
Die übliche Skala ist eine modifizierte Fibonacci-Folge, im oberen Bereich gerundet: 1, 2, 3, 5, 8, 13, 20. Die Abstände wachsen, je höher die Zahlen steigen, was eine Diskussion zwischen 12 und 13 über ein Item ausschliesst, von dem man fast nichts weiss. Zwei benachbarte Werte im unteren Teil der Skala decken Arbeiten ab, deren Unterschied das Team wahrnimmt; zwei benachbarte Werte im oberen Teil decken Arbeiten ab, die es nicht auseinanderhalten kann. T-Shirt-Grössen (XS, S, M, L, XL) wenden dasselbe ordinale Prinzip auf Etiketten an.
Das Team wählt eine Referenz-Story: ein bereits geliefertes Item, klein, von allen verstanden, dem es eine 2 oder eine 3 gibt. Alle anderen Grössen werden an dieser einen ausgerichtet. Ein Item, das grösser ist als die grösste Karte des Sets, verlangt eine Zerlegung, auf die die Sitzung hinweist, bevor das Item in eine Iteration geht.
Die Skala in Gang bringen
Die Agile Extension bietet einem Team ohne bisherige Historie drei Ausgangspunkte. Der erste ist die Grössenordnung: grob bemessen, über die folgenden Iterationen nachjustieren. Der zweite geht von einem gegebenen Satz an Ressourcen und einer Iteration fester Dauer aus und lässt dann die erste Iteration zeigen, was darin Platz hat. Der dritte lässt das Team eine Stichprobe von Stories unterschiedlicher Grösse in Zeit schätzen und rechnet daraus hoch, was eine Iteration aufnehmen kann.
Wie genau diese drei Ausgangspunkte sind, spielt kaum eine Rolle: Die Agile Extension hält fest, dass die ersten Schätzungen gröber ausfallen als die kurz vor der Auslieferung, und die Technik gewinnt ihren Wert aus der Korrektur, die jede Iteration bringt.
Planning Poker
Planning Poker bemisst die Items in der Sitzung, mit dem ganzen Team, in der Regel während des Planungsworkshops. Das Team geht ein Backlog-Item so lange durch, bis alle dasselbe darunter verstehen. Danach wählt jedes Mitglied verdeckt eine Karte auf der Punkteskala, und alle Karten werden gleichzeitig aufgedeckt. Liegen die Werte innerhalb eines Schritts beieinander, behält das Team einen davon und geht zum nächsten Item über. Ist die Streuung gross, spricht es über das Wissen, das eine Person hat und die anderen nicht, jenes Wissen, das erklärt, warum dasselbe Item der einen als 3 und der anderen als 13 erscheint. Die Sitzung zielt auf die Einigung über jedes Item.
Der ganze Mechanismus hängt am gleichzeitigen Aufdecken: Es verhindert, dass der zuerst genannte Wert die folgenden festlegt. James Grenning hat die Technik 2002 formalisiert, Mike Cohn hat sie 2005 in der agilen Praxis verbreitet.
Magic Estimation
Magic Estimation, in der Agile Extension unter §7.13.4 Silent Sizing genannt, bearbeitet ein ganzes Backlog durch das Verschieben von Karten, ohne zu sprechen. Das Team bereitet ein Kartenset vor, ein Item pro Karte. Es braucht zudem eine Wand oder einen Tisch, um die Karten in einer Linie auszulegen. Reihum nimmt jede Person eine Karte und legt sie auf die Linie, die kleinsten Items an das eine Ende, die grössten an das andere; ein Mitglied darf eine bereits gelegte Karte verschieben. Die Runde wiederholt sich, bis alle Karten auf der Linie liegen. Danach sucht das Team die Brüche, die Stellen, an denen der Grössenabstand zwischen zwei benachbarten Karten wächst, und bildet Gruppen. Erst dann erhält jede Gruppe einen Wert von der Skala, und jede Karte übernimmt den Wert ihrer Gruppe.
Die relative Position steht fest, bevor es eine Zahl gibt. Der Preis ist das Schweigen: Das Wissen, das eine Diskussion zutage gefördert hätte, bleibt bei dem, der es besitzt.
Vor der Gruppierung, nur die Position
Nach der Gruppierung erscheint der Wert
Die Velocity und die Umrechnung in einen Termin
Die Velocity ist die Summe der in einer Iteration fertiggestellten Punkte. Über mehrere Iterationen hinweg misst sie den Durchsatz des Teams, auf dem dessen nächste Zusagen beruhen. Sie wird als Bandbreite gelesen: Ein Team, das 34, 41, 38 und 45 Punkte geliefert hat, nennt eine Bandbreite von 34 bis 45 Punkten. Ein einzelner Mittelwert, 39,5, gäbe dem Ausschuss eine Genauigkeit, die vier Messungen nicht hergeben.
Die Punktsumme des Umfangs, geteilt durch die tiefe und dann durch die hohe Velocity, ergibt eine Anzahl Iterationen als Bandbreite. Die Kosten ergeben sich, indem diese Anzahl mit den Vollkosten einer Iteration multipliziert wird, dem Wert, den die Kostenrechnung ohnehin führt. Die Umrechnung läuft somit immer über die Velocity. Ein Preis pro Punkt umgeht sie und kappt die einzige Verbindung, die die Punkte an eine echte Menge band.
Was die Schätzung verfälscht
Der feste Umrechnungssatz
Festzulegen, dass ein Punkt vier Stunden wert ist, führt die Einheit wieder ein, die die Technik gerade weglässt. Das so fixierte Verhältnis verschiebt sich bei jeder Änderung der Teamzusammensetzung. Das Team bewertet die Items dann im Kopf in Stunden und dividiert, um die zu spielende Karte zu finden. Die fünf Faktoren verschwinden, die Unsicherheit mit ihnen. Übrig bleibt eine Schätzung in Stunden, als Punkte verkleidet.
Der Vergleich zwischen Teams
Die Zahlen gehören dem Team, das sie vergeben hat. Eine 5 beim einen Team hat nichts mit einer 5 beim anderen zu tun, und die Agile Extension führt den Vergleich zwischen Teams unter den Grenzen der Technik auf, wegen der Verwirrung, die er bei den Stakeholdern stiftet. Verglichene Velocity wird zur Leistungskennzahl, und ein Team, das an seiner Velocity gemessen wird, steigert sie innerhalb einer Iteration, indem es höher bewertet. Die Zahl steigt, die gelieferte Arbeit bleibt gleich.
Der Ankereffekt in der Sitzung
Ein Architekt, der seinen Wert vor dem Aufdecken nennt, nimmt der Sitzung, was sie hervorbrachte: unabhängig gebildete und danach gegenübergestellte Urteile. Derselbe Ankereffekt stellt sich unauffälliger ein, wenn die Karten reihum von links nach rechts gezeigt werden. Die Reihenfolge des Aufdeckens wird deshalb im Voraus festgelegt.
Die verschwiegene Neukalibrierung
Ein Team kalibriert seine Skala mit der Zeit neu: Was es vor sechs Monaten mit 3 bewertete, bewertet es heute mit 2. Der Schritt ist gesund, macht aber die alte Velocity mit der neuen unvergleichbar. Eine Neukalibrierung, die nicht angekündigt wird, erzeugt eine Velocity-Kurve, die ohne Grund abzusacken scheint, und eine Ausschussdiskussion über einen Leistungseinbruch, den es nie gab. Die Gegenmassnahme besteht darin, die Neukalibrierung zu datieren und von der neuen Bandbreite aus weiterzurechnen.
Die Schätzung als Termin gelesen
Die Agile Extension nennt zwei Fehldeutungen durch Stakeholder ausserhalb des Teams. Die erste nimmt die relative Schätzung für einen verbindlichen Termin. Bei der zweiten richtet sich die Aufmerksamkeit auf die Schätzung, die ein Zwischenprodukt ist, während das gesuchte Ergebnis der gelieferte Wert ist. Die Antwort darauf ist die Umrechnung: eine Bandbreite von Iterationen und die daraus folgenden Kosten, bei jeder Iteration überarbeitet. Ein Ausschuss, dem man eine Punktsumme zeigt, will immer wissen, was ein Punkt wert ist.
KI-Überlegungen
Vor der Sitzung arbeitet ein Sprachmodell auf dem Backlog und auf der Historie des Werkzeugs. Es erkennt die Items, deren Beschreibung keine Beurteilung der Grösse zulässt, jene, die sich mit einem bereits gelieferten Item decken, dessen frühere Grösse als Vergleich dient, und jene, die die grösste Karte des Sets überschreiten und für die es eine Zerlegung vorschlägt. Auf der Historie berechnet es die Bandbreite der Velocity, hebt die untypischen Iterationen heraus und meldet eine Verschiebung der Skala, indem es die durchschnittliche Grösse der Items von Quartal zu Quartal vergleicht.
Die Zahl selbst bleibt beim Team. Ein Modell, das nach der Grösse eines Items gefragt wird, liefert einen plausiblen Wert aus anderen Projekten, während die fünf Faktoren alle darauf zielen, was dieses Team weiss, bereits gemacht hat und nicht kennt. Der Wert kommt also auf einer Skala kalibriert an, die der Historie fremd ist, aus der das Team seine eigene gewonnen hat. Grösser noch ist das Risiko, wenn das Modell in die Sitzung selbst eingebunden wird: Ein Vorschlag, der vor dem Aufdecken der Karten angezeigt wird, ist ein Anker wie jeder andere. Zudem enthält ein Backlog Kundensegmente, Beträge und regulatorische Vorgaben, die das Unternehmen nicht verlassen sollen, und sie werden vor jeder Übermittlung an ein öffentliches Modell entfernt.
Beispiele
In einer Schweizer Retailbank bemisst das Team des Digital-Banking-Produkts die Items des Moduls zur Hypothekensimulation seiner Mobile-App, vor der Budgetprüfung des Lenkungsausschusses. Das Kartenset reicht von 1 bis 20 und die Referenz-Story, mit 2 bewertet, ist das Hinzufügen eines Feldes zum Simulationsformular, zwei Iterationen zuvor geliefert.
| Backlog-Item | Grösse | Der Faktor, der die Zahl bestimmt hat |
|---|---|---|
| PDF-Export des Simulationsergebnisses | 2 | Grösse: bestehende Vorlage, ein Bildschirm, keine neue Regel. |
| Biometrische Anmeldung über die bestehende E-Banking-App | 3 | Erfahrung: Das Team hat denselben OAuth-Mechanismus bereits zweimal eingebunden. |
| Tragbarkeitsprüfung nach den internen Kreditregeln der Bank | 5 | Komplexität: sieben Berechnungsregeln, jede mit eigenen Schwellenwerten und Ausnahmen. |
| Echtzeit-Feed der Hypothekarzinsen eines neuen externen Anbieters | 13 | Unsicherheit: Niemand hat die Schnittstelle dieses Anbieters je eingebunden. |
| Übernahme der gespeicherten Simulationen aus dem alten Portal | 20 | Wissen: Das ursprüngliche Speicherformat ist nirgends dokumentiert. |
Der Zinsfeed startete geteilt zwischen 5 und 13. Die Diskussion brachte zutage, dass der Anbieter für alle neu war, und das Team entschied sich allein aus diesem Grund für 13, ohne dass sich das erwartete Arbeitsvolumen geändert hätte. Die Übernahme der Simulationen liegt aus einem verwandten Grund an der Obergrenze des Sets: Nichts von dem, was das Team geliefert hat, ähnelt ihr. Die Genauigkeit der Technik hängt an dieser Ähnlichkeit.
Über die vorangegangenen vier Iterationen hat das Team 38, 44, 36 und 42 Punkte fertiggestellt, also eine Bandbreite von 36 bis 44 Punkten pro zweiwöchiger Iteration. Der dem Ausschuss vorgelegte Umfang summiert sich auf 210 Punkte, was fünf bis sechs Iterationen ergibt. Bei Vollkosten von CHF 45'000 pro Iteration und beim aktuellen Personalbestand erhält der Ausschuss eine Bandbreite von CHF 225'000 bis CHF 270'000 und das dazugehörige Datum. Einen Preis pro Punkt erhält er zu keinem Zeitpunkt.
Visualisierungen
Die Zeichnung, die die Technik vermittelt, ist die Linie der Magic Estimation. Eine erste Reihe zeigt die Item-Karten, nacheinander gelegt, von der kleinsten zur grössten, ohne dass eine Zahl erscheint. Dieselbe Reihe darunter ist an den Abstandsbrüchen in vier Gruppen geschnitten, und jede Gruppe erhält dann ihren Wert von der Skala.
Die zweite Abbildung ist die Tabelle des bemessenen Backlogs: ein Item pro Zeile, seine Grösse und der Faktor, der sie erklärt.
Aufwand
| Phase | Stufe | Begründung |
|---|---|---|
| Vorbereitung | Gering | Ein durch Backlog Refinement verfeinertes Backlog und ein Kartenset, physisch oder online. Die Referenz-Story wird ein für alle Mal gewählt. |
| Durchführung | Mittel | Ein bis zwei Stunden mit dem vollständigen Team, bei jeder Iteration. Magic Estimation deckt das ganze Backlog in einem Durchgang ab, ohne Diskussion Item für Item. |
| Dokumentation | Gering | Die Grösse ist ein Attribut des Items im Backlog-Werkzeug, und die Velocity berechnet sich dort von selbst. |
Werkzeuge
Backlog-Werkzeuge (Jira, Azure DevOps, GitLab und ihresgleichen) führen das Punktefeld am Item und berechnen die Velocity aus dem, was fertiggestellt wurde. Sie sind zugleich die Quelle der Historie, von der die Technik lebt: Ohne verlässliche Erhebung pro Iteration ist die Velocity eine Meinung.
Werkzeuge für gleichzeitiges Abstimmen (Planning-Poker-Anwendungen, Vorlagen für kollaborative Whiteboards) machen das gleichzeitige Aufdecken für ein verteiltes Team praktikabel, was eine Videokonferenz ohne Abstimmungsfunktion nicht leistet: Dort nennt immer jemand seine Zahl vor den anderen.
Das physische Kartenset bleibt für ein Team am selben Standort das schnellste Mittel, und die Wand mit ihren Karten ist die einzige Anordnung, in der Magic Estimation ihr natürliches Tempo erreicht. Aus der Distanz bildet ein kollaboratives Whiteboard die Linie und die Gruppen nach, um den Preis langsamerer Handhabung.
Die Tabellenkalkulation genügt, um die Bandbreite der Velocity und die Umrechnung in Iterationen und Franken zu führen, ein paar Zeilen, die man dem Lenkungsausschuss zeigt.
Quellen
- IIBA, Agile Extension to the BABOK Guide, §7.13 Relative Estimation: der Zweck der Technik, der schrittweise Charakter der Schätzung im agilen Umfeld, die drei Beiträge für die Stakeholder, die fünf Faktoren hinter der Grösse einer Story, die Fibonacci-Skala, die Definition der Velocity, die drei Ausgangspunkte für eine Skala, Planning Poker und Silent Sizing sowie die dort genannten Stärken und Grenzen, darunter die Abhängigkeit der Genauigkeit davon, wie stark neue Stories den bereits gelieferten ähneln, der Vergleich zwischen Teams, die Schätzung als verbindlicher Termin gelesen und die Aufmerksamkeit für das Zwischenprodukt statt für das Ergebnis.
- IIBA, Agile Extension to the BABOK Guide, §4.7.1, §5.7.1 und §6.7.1, die Techniken nach Planungshorizont: der Einsatz der Technik auf dem Horizont Strategie, um Wert und Ressourcen der Initiativen eines Portfolios einzuordnen, und auf den Horizonten Initiative und Lieferung, um zu entscheiden, welche Funktionen in welcher Reihenfolge geliefert werden.
- IIBA, A Guide to the Business Analysis Body of Knowledge (BABOK Guide) v3, §10.19 Estimation: die allgemeine Schätztechnik, auf der die Agile Extension aufbaut und deren Anpassung an das agile Umfeld sie beschreibt.
- Mike Cohn, Agile Estimating and Planning, Prentice Hall, 2005: die Praxisreferenz, die die Story Points, die Referenz-Story, das im oberen Bereich gerundete Fibonacci-Kartenset und die Velocity als einzigen Weg der Umrechnung in einen Terminplan verbreitet hat.
- Mike Cohn, Agile Estimating: How Teams Estimate with Story Points, Mountain Goat Software: die Unterscheidung zwischen relativem Aufwand und absoluter Dauer sowie der für jedes Team eigene Charakter der Punkteskala.
- Agile Alliance, Glossareintrag Planning Poker: der Ablauf der Technik und ihre Formalisierung durch James Grenning im Jahr 2002, dann ihre Verbreitung durch Mike Cohn im Jahr 2005.