.st0{fill:#FFFFFF;}

Scrum Toolbox

Agiles Schätzen: das steckt dahinter!

 September 2, 2016

von  Sebastian

Agiles Schätzen ist eine Technik zum Schätzen, die bei der Produktentwicklung im agilen Kontext verwendet wird, zum Beispiel mit Scrum. Es gibt einige Methoden, die sich etabliert haben und in diesem Umfeld immer genannt werden. Ebenso liegen einige Grundkonzepte dahinter, auf die wir einen Blick werfen.

Grundlagen

Aufwand

Aufwand ist etwas, das wir tagtäglich schätzen: Wie lange dauert es, bis wir die Kinder vom Kindergarten abgeholt haben, wie viel Zeit benötigen wir wohl, bis wir unsere Einkaufsliste abgearbeitet und aus dem Supermarkt zurück sind. Schaffen wir es noch pünktlich zum Endspiel nach Hause?

Diese Schätzungen sind recht einfach und lassen sich in Stunden (oder einer anderen Zeitangabe) wunderbar ausdrücken. Natürlich nutzen wir intuitiv auch so etwas für unsere Arbeit. Ich brauche 3 Sunden, um das Konzept zu schreiben, bestimmt nur 30 Minuten die neue Klasse zu implementieren und für die Inbetriebnahme der Hardware braucht der Klaus bestimmt gute zwei Wochen.

Jetzt stellen wir fest, dass meine Frau immer länger für das Holen der Kinder benötigt als ich. Der Klaus komischerweise immer doppelt so lange an Zeit für die Inbetriebnahme der Hardware benötigt als ich, und man in 30 Minuten doch nie diese Klasse implementiert haben kann. Warum ist das so?

Ganz einfach: Meine Frau hält immer noch ein Schwätzchen mit der Erzieherin im Kindergarten, die Klasse kann man nur in 30 Minuten schaffen, wenn man zu den besten seiner Programmiersprache gehört und der Klaus ist einfach noch nicht lange im Unternehmen, will nichts falsch machen und macht deshalb alles sehr gewissenhaft – und das dauert einfach.

Wir haben teilweise sehr hohe Schwankungen in den Schätzungen, weil der Aufwand immer personenbezogen ist und jeder seine Erfahrungen und Erlebnisse mit in diese Aufwandsschätzungen interpretiert. Das hat die unangenehme Eigenschaft, dass wir zum einen nur auf Basis der schätzenden Person Aussagen machen können und zum anderen sind diese Schätzungen nicht belastbar.

Komplexität

Da der Aufwand – wie wir eben gelernt haben – personenbezogen ist und teilweise sehr stark variieren kann, führen wir doch einfach ein abstraktes Schätzmaß ein, welches unser agiles Schätzen erleichtert: die Komplexität. Nun, zuerst kommt die Frage, was die Komplexität denn nun sei. Welche Faktoren spielen in eine Komplexität hinein? Die Komplexität ist dummerweise nicht so ganz einfach und jedes Teammitglied kommt damit sofort klar.

Nehmen wir den Weg in den Kindergarten. Lassen wir die personenbezogene Erfahrung einmal weg. Was kann also die Komplexität des Kindergartenweges beeinflussen? Wie können meine Frau und ich auf die gleiche Komplexität (nicht Aufwand) kommen? Wir könnten zum Beispiel die Wahl des Verkehrsmittel berücksichtigen (ein Auto zu bedienen ist komplexer als zu Fuß zu gehen), mögliche Weghindernisse (zum Beispiel Ampeln), etc. Wenn wir noch keinen Referenzpunkt haben (siehe weiter unten) dann könnten wir nun sagen, für die Komplexität Kindergarten vergeben wir die 2. Jetzt sehen wir uns das Einkaufen an und bestimmen die Komplexität relativ gegen diesen Wert und würden zum Beispiel zu einer 5 gelangen.

Wenn wir uns nachher entscheiden, wer die Aufgabe wirklich macht, nutzen wir personenbezogene Schätzungen, die auch in Stunden sein können. Auf dieser abstrakten Ebene (die nachher die Product Backlog Ebene zum Beispiel sein kann) wollen wir das aber nicht nicht tun.

Klar sollte auch sein, die Komplexität ist eine teambezogene Größe und immer abhängig vom Team.

Korrelation von Aufwand und Komplexität

Nehmen wir an, du hast eine hohe Komplexität für eine Funktionalität bestimmt. Was glaubst du, was das Team als Aufwand schätzen wird? Er wird hoch sein, haben Sie eine geringe Komplexität, dann wir der Aufwand geringer sein. Selten sind die Fälle, das eine sehr komplexe Aufgabe mit wenig Aufwand zu lösen ist. Irgendwo steckt also inhärent der Aufwand auch in der Komplexität, spätestens dann, wenn Sie sich an die Arbeit machen.

Wir werden später noch sehen: es muss nicht immer die Komplexität sein, es lassen sich auch andere „Werte“ ganz ausgezeichnet benutzen.

Prinzipien für das Schätzen

Geschwindigkeit

Agiles Schätzen lebt von der Geschwindigkeit. Dazu muss die verwendete Technik besonders schnell sein, gerade wenn wir Product Backlog Einträge abschätzen wollen. Es geht darum, schnell zu sein und keine Zeit in unnötige Planungen zu investieren.

Zusammenarbeit

Agiles Schätzen basiert auf einer gemeinsamen Zusammenarbeit. Das Team schätzt gemeinsam und es geht nicht darum, einzelne Mitglieder zu blamieren.

Relatives Schätzen

Agiles Schätzen basiert nicht auf dem absoluten Aufwand, sondern immer zu einem Referenzwert und alle weiteren Schätzungen findet relativ zu diesem statt. Wir können sehr schnell sagen, ob A komplexer ist als B – ob A aber 10 Stunden oder 11 Stunden dauert ist schwierig – und das wollen wir hier auch noch gar nicht wissen!

Konstanz

Komplexität ändert sich nicht über die Laufzeit. Ein sehr komplexes Feature ist immer komplex. Auch kurz vor dem Ende. Ein Aufwand muss über die Laufzeit des Projektes angepasst werden und nimmt

Objektivität

Komplexität lässt gleich zu Beginn die Individuen außen vor. Es hilft sich auf das Wichtige zu konzentrieren und nicht indirekt in Aufwand zu denken.

Unterschiedliche Methoden

Planning Poker

Planning Poker ist bestimmt eine, wenn nicht die, bekannteste Methode um agiles Schätzen durchzuführen. Dabei gibt es pro Teammitglied einen Satz „Poker-Karten“. Das sind in der Regel Karten, die eine leicht geänderte Fibbonacci-Folge aufgedruckt haben. Je größer die Zahlen werden, desto größer wird auch der Abstand zwischen diesen. Der Abstand zwischen 1 und 2 ist Faktor 2, wenn wir und die nächsten Zahlen ansehen, haben wir 2 und 5 – hier ist der Faktor nicht mehr doppelt so groß, sondern schon „etwas mehr“.

agiles Schätzen: Planning Poker

Je weiter wir dann und von kleinen Zahlen wegbewegen, desto größer wird auch der Unsicherheitsfaktor im Schätzen (siehe auch Cone of Uncertainty). Der wirkliche Benefit von Planning Poker ist in meinen Augen der Konsens des Entwicklungsteams. Denn es wird im Team ein Product Backlog Item geschätzt (verdeckte Karten jedes Mitglieds) und dann wird gemeinsam auf die ausgewählten Werte der Teammitglieder geschaut, wenn alle gleichzeitig die Werte umdrehen. Wer den höchsten und den niedrigsten Wert geschätzt hatte, erläutern Ihre Argumente. Dann wird erneut geschätzt – das ganze i.d.R. drei mal. Es ist überraschend, wie schnell Konsens herrscht.

Ablauf im Detail

Planning Poker kannst du recht einfach durchführen. Ich habe Planning Poker in meinem Scrum Kurs bei Lecturio auch beschrieben - schau doch gerne mal rein. Der Ablauf ist hier wie folgt:

  • Jedes Teammitglied bekommt einen Satz an Poker Karten.
  • Das Product Backlog Item wird vorgestellt.
  • Wenn keine Fragen zum Product Backlog Item existieren, sollte die Referenzstory noch mal in die Köpfe gerufen werden und dann das aktuelle Product Backlog Item gegen diese Referenzstory geschätzt werden.
  • Das tut jedes Mitglied aus dem Entwicklungsteam erst einmal für sich im Geheimen. Es wählt also erst einmal aus, was in dem eigenen Verständnis die richtige Komplexität wäre.
  • Haben das alle Teammitglieder getan, werden alle Karten gleich umgedreht.
  • Die höchste und niedrigste Abweichung wird dann diskutiert. Dabei geht es darum herauszufinden, welche Gründe hinter dieser Annahme stecken
  • Sind die Gründe klar, dann erfolgt eine neue Runde
  • In der Hoffnung, dass es maximal drei Runde braucht, wird dieser Vorgang wiederholt, bis sich die Werte angeglichen haben.

3 Runden und Akzeptanz

Man muss es nicht dogmatisch machen. Wenn es keine drei Runden braucht, dann umso besser. Es kann situativ auch Sinn machen, mal vier Runden zu spielen. Ebenso kann es okay sein, wenn Teammitglieder es wie Schuppen von den Augen fällt und sich alle nach der ersten Runde auf einen Wert einigen. Es gibt kein richtig oder falsch. Es ist ein Kommunikationstool. Und so solltest du es auch verstehen.

Planning Poker remote durchführen

Planning Poker remote durchzuführen ist auch keine große Sache. Hier kannst du dich sehr gut an meinem Artikel auf dem Agile Team Facilitator Blog orientieren. Dort habe ich gezeigt wie man Delegation Poker remote durchführen kann.

Sonst kannst du dich an Magic Estimation orientieren, auch hier ist der Ablauf sehr identisch.

T-Shirt Größen

Das Schätzen mit T-Shirt-Größen eignet sich besonders für Teams, die gerade mit dem Schätzen starten. Es ist neben dem Planning Poker und Magic Estimation eine sehr verbreitete Art der relativen Schätzung für agile Teams, um das Product Backlog abzuschätzen.

Hier werden zum Beispiel S,M,L und XL als Größen festgelegt und diese stehen dann für die Komplexität / Größe für Aufgaben. Bei den T-Shirt Größen einigt sich das Team auf eine Referenzstory und schätzt dann alle anderen Werte dagegen. T-Shirt Größen funktionieren immer dann sehr gut, wenn Sie analog mit einem Backlog / Board arbeiten. Nutzen Sie digitale Tools, sollten Sie ein Blick auf das Werkzeug werfen: sind hier Eingaben von T-Shirt Größen möglich?

Das Schöne an T-Shirt Größen ist, das diese jeder im Team und in der Organisation kennt. Jeder hat schon mal ein T-Shirt angehabt und kennt sich mit den Größen aus. Indirekt werden diese Größen umgerechnet. Das ist faktisch auch das, was immer bei solchen Ansätzen probiert wird. T-Shirt Größen und Story Points können so hin und her gerechnet werden. Ein schönes Beispiel für Erfahrungen mit T-Shirt Größen finden Sie auf diesen Seiten.

Infografik agiles Schätzen T-Shirt

Agiles Schätzen bei T-Shirt Größen ist vom Vorgehen einfach: Zuerst wird sich das zu schätzende PBI angesehen und vom Team gemeinsam nach Abstimmung einer dieser Größen zugeordnet. Dabei ist darauf zu achten, dass alle „Zwischengrößen“ in die nächste Größe einsortiert werden. Das kann und sollte in der Regel im Refinement geschehen, bei dem es auch der Product Owner vorstellt. Da das agile Schätzen aber schnell ist, können einzelne Elemente auch noch im Sprint Planning geschätzt werden.

agiles Schätzen T-Shirt Größe

Die Velocity bekommen Sie natürlich nur dann heraus, wenn Sie in irgendeiner Art und Weise die T-Shirt Größen mit Werten belegen. Es ist schwer zu argumentieren, wir schaffen 3xS, 4xM und 1xL im Sprint. Folglich gibt es direkt oder auch indirekt das Umrechnen in Werte. Zum Beispiel bekommt M dann eine 5 und so wird dann die Velocity bestimmt.

Magic Estimation

Mit Magic Estimation können größere Backlogs mit mehreren Parteien schnell geschätzt werden. Es eignet sich daher ideal zu Beginn eines Projektes, wenn noch keine Schätzungen vorliegen. Von Magic Estimation gibt es verschiedene Varianten. Meine bevorzugte ist die, dass die Planning Poker Karten ausgelegt werden, am besten auf dem Boden. Dann werden die zu schätzenden Product Backlog Einträge (PBI) verteilt und von den Personen zu den (aus deren Sicht) korrespondierenden Story Points gelegt.

agiles Schätzen: Magic Estimation

Nicht jeder wird jeder Zuordnung zustimmen und folglich darf dann auch eine Karte umgelegt werden. Wird das getan, bekommt diese Karte dann eine Markierung (zum Beispiel einen Punkt). Ähnlich wie beim Planung Poker werden dann nur diese PBI besprochen.

Der Magic Estimation Ablauf im Detail

Im Folgenden stelle ich dir einen möglichen Ablauf für ein agiles schätzen mit Magic Estimation vor. Es gibt Varianten, die du immer mal ausprobieren kannst und deiner aktuellen Situation auch anpassen solltest. Als Orientierung tut es der folgende Ablauf allemal.

Gutes Refinement ist Voraussetzung

Achte immer darauf, dass die zu betrachtenden Items schon recht gut refined sind. Sonst wirst du zu vielen Diskussionen bei Magic Estimation erleben. Das ist zwar auch ein guter Indikator, wird aber häufig von vielen dann direkt mit der Methode in Verbindung gebracht und dann nicht oder nur schlecht akzeptiert.

  • Lege die (angepasste) Fibonacci Reihenfolge am besten auf dem Boden oder einen großen Tisch aus.
  • Drucke einen Stapel der zu schätzenden Product Backlog Items aus.
  • Lade das Entwicklungsteam ein und verteile deinen Stapel der ausgedruckten PBI's zufällig an die Teammitglieder.
  • Setze eine Timebox und lasse alle Teilnehmer die Einträge in Relation zu eurer Referenzstory einsortierten: jedes Teammitglied kann das eigenständig tun - oft sogar parallel oder ich macht es der Reihe nach und jeder liest die Karte noch mal vor und legt sie dann ab,
  • Wenn alle Karten gelegt sind, dann gebe erneute eine gewisse Zeit, das sich jeder die Product Backlog Items in Ruhe ansehen kann. Ist dann jemand der Meinung er möchte eine Karte umlegen, dann kannst du das einfach mit einem Punkt oder Strich auf der Karte vermerken und es geschehen lassen.
  • Möchte jemand anderes diese Karte wieder umlegen oder auch eine andere, dann lasse auch das geschehen - nur die Markierung muss stattfinden
  • Sollte ein PBI zum Beispiel drei Punkte oder Strichte bekomme, dann wird diese Karte auf die Seite gelegt - scheinbar muss noch genauer über die gesprochen werden.
  • Meistens kommst du so auf eine Anzahl von ca. 80% oder mehr, die recht schnell geschätzt sind.
  • Sortiere diese Einträge in das Product Backlog ein. Diese können in den kommenden Refinements immer noch einmal erneut geschätzt werden.

Magic Estimation remote durchführen

Magic Estimation kannst du auch ohne Probleme remote durchführen. Dabei gilt im Grunde der gleiche Ablauf die oben. Denke an die folgenden Abweichungen für die 

  • Du druckst die Product Backlog Items bei der remoten Durchführung nicht aus, sondern bereitest diese in einem Whiteboard Tool vor. Das kann zum Beispiel Conceptboard oder ein anderes Tool deiner Wahl sein. Achte darauf, dass die Teilenehmer die Tools kennen. Wenn du Conceptboard nutzen möchtest, helfen dir meine beiden YouTube Videos: Als agiles Team sofort auf Conceptboard einsatzbereit sein und Orientierung auf dem Conceptboard.
  • Überlege dir aber, wie du diese Product Backlog Items in Tool bekommst. Unterschiedliche Tools haben unterschiedliche Ideen und benötigen so ggf. eine Vorbereitung.
  • Auch hier kannst du dann eine entsprechende Reihe mit den Boardmitteln des Tools aufsetzen und vorbereiten.

Agiles Schätzen: meine Erfahrungen

Für mich stellt sich immer eine Frage: Was nützt es dem Team? Mit dieser Fragestellung gehe ich gerne in Retrospektiven, frage mich das bei Scrumeinführung und spreche in Kaffeeküchen gerne mit Mitarbeitern, die agiles Schätzen anwenden, es wollen oder sich einfach nur dazu einen Vortrag von mir angehört haben.

  1. 1
    Komplexität ist sehr schwer zu begreifen! Relativität stellt sich recht schnell ein und von der Schnelligkeit sind nicht wenig Teams regelrecht begeistert! Agiles Schätzen funktioniert bei – ich erwähnte es zu Beginn schon – cross-funktionalen Team sehr gut. Je weniger Teams interdisziplinär sind, desto mehr ist die Vorliebe für den Aufwand vorhanden.
  2. 2
    Agile Schätzen muss ausprobiert werden! Es ist ein sehr wichtiger Teil von Scrum. Wenn du mit Scrum startest, ist gerade das Ausprobieren wichtig, um die Unterschiede kennen zulernen. Hier helfen zudem gute Experimente. Nur wer Experimente durchführt, der lernt auch. Denke auch an die Struktur, damit sich eine Kultur findet, in der agiles Schätzen funktioniert.
  3. 3
    Oft finden sich schnell Grenzen auf Basis der Story Points. "Wie? die Story ist 13 Punkte? Das passt nicht mehr in den Sprint". Das kann ein guter Indikator sein, auf der anderen Seite birgt so eine Aussage auch die Gefahr von einem umgerechneten Aufwand, bei dem die Größe umgeschlagen wird. Rein von der Komplexität muss das nicht zutreffen sein. Augen auf!
  4. 4
    Da nicht alle Teams gleich sind und nicht alles überall funktioniert, ist das Ausprobieren wichtig: Aufwand, Komplexität, idealisierte Story Points, Normwochen oder idealisierte Sprints? Ich persönliche habe Favoriten und gebe gerne einen Rat - nur ausprobieren und verinnerlichen müssen es die Teams. Nur was nachhaltig übernommen wird, hat auch eine Chance gut zu werden.

Agiles Schätzen: Herausforderungen

Ich möchte hier noch auf den einen oder anderen Punkt eingehen, der dir bei der Einführung oder dem Umgang mit agilen Schätzen sicher begegnen wird. Nutze diesen Bereich bitte als Reflexion und so bekommst du hoffentlich noch den einen oder anderen Impuls.

Komplexität nutzen ist nicht leicht - gerade zu Beginn

Sich wirklich frei von Aufwand zu machen und eine Komplexität zu schätzen ist kein leichtes Vorhaben. Denn wir sind oft lange darauf konditioniert worden, in Stunden zu schätzen. Deswegen stellt das viele Teams und gerade ältere Kollegen in den Teams vor eine Herausforderung.

Warum die Schätzung mit Manntagen eine Dysfunktion ist

Während ich früher der Meinung war, dass statt Story Points mit Fibonacci auch recht problemlos Manntage genutzt werden können, sehe ich das heute etwas differenziert. Die meisten Unternehmen, die das wollen und Teams, die das nutzen haben in der Regel eines der folgenden Probleme:

  • Es besteht kein wirkliches Team. Die Teammitglieder schätzen immer noch auf Basis der eigenen Aufwände und verfügbaren Stunden
  • Die Teams sind oft weiter unterteilt und arbeiten an unterschiedlichen Dingen und auch in unterschiedlichen Projekten
  • Es geht um eine kapazitative Planung und die wertgetriebene Planung aus Scrum ist nicht umgesetzt

Sebastian

Ein paar Worte über den Autor

Agile Team Facilitator Sebastian Schneider
ICP-ACC Sebastian Schneider
Sebastian Schneider CSP
Sebastian Schneider CSP-PO

Sebastian Schneider ist dem Framework Scrum - es war Liebe auf den ersten Sprint - bereits seit 2005 verfallen. Seitdem begleitet er Unternehmen (meist größere) bei der Transition in eine neue Arbeits- und Produktwelt. Dafür findet er den richtigen Grad zwischen zielgerichteten systemischen Impulsen und dem nachhaltigen Coaching in der Organisation, um diese bei der Entwicklung und Optimierung des eigenen Kundenmehrwerts zu unterstützen und entwickelt mit ihnen Produkte, die ihre Kunden lieben. Im richtigen Maß gehören dazu die effektive und effiziente Facilitation dazu, sowie agile Spiele und Simulationen, die sein Themenfeld auf einfache Art begreiflichen machen. Auf Konferenzen, sei es im Fachbeirat oder als Akteur, gibt er gerne Erkenntnisse weiter und freut sich über Kontakte von Angesicht zu Angesicht.

  • Wenn ich zwei Stories habe, die beide eine Komplexität von 5 haben und die eine würde in den Sprint passen weil sie leicht umzusetzen ist, die andere aber nicht. Welchen Nutzen hat dann die Schätzung?

    • Hallo Irene,

      recht herzlichen Dank für diese Frage 🙂

      Aus meiner Sicht hat das dann keinen Nutzen. Wenn Komplexität richtig genutzt wird, dann passt die 5 (z.B. empirisch ermittelt) immer in den Sprint. Das bedeutet, die eine User Story mit 5 Story Points ist nicht leichter oder schwerer umzusetzen als die andere User Story mit 5 Story Points.

      Viele Grüße
      Sebastian

  • {"email":"Email address invalid","url":"Website address invalid","required":"Required field missing"}

    Sei auch mit dabei: Der Newsletter zu Scrum aus Augsburg.

    __CONFIG_colors_palette__{"active_palette":0,"config":{"colors":{"62516":{"name":"Main Accent","parent":-1}},"gradients":[]},"palettes":[{"name":"Default Palette","value":{"colors":{"62516":{"val":"var(--tcb-skin-color-0)"}},"gradients":[]}}]}__CONFIG_colors_palette__
    Hier gehts lang!
    >

    Psssst - hier gibts was sehr cooles!

    Der Scrum Newsletter

    Willst du mal schauen? :-)