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“.
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:
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. Meist nutzt du Seiten wie PointingPoker oder ähnliche als Tool. Dazu 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.
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.
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.
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.
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
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.
- 1Komplexitä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.
- 2Agile 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.
- 3Oft 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!
- 4Da 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: