User Stories nicht zu schätzen, ist häufig keine Option!
Wir alle kennen die Argumente, warum wir User Stories nicht schätzen sollten. Das Schätzen kostet viel Zeit. Story Points oder T-Shirt-Größen können Stakeholder verwirren. Zudem ist das Schätzen ungenau. Es genügt oft, die Anzahl der Einträge pro Sprint zu zählen. Wer meinen Newsletter bereits seit einiger Zeit verfolgt, weiß das sicherlich. Ich bin kein Befürworter des Schätzens.
Allerdings bin ich auch Realist und nicht Ideologe.
Manchmal sind wir einfach in einer Situation, in der verlangt wird, dass User Stories geschätzt werden. Und die bittere Wahrheit ist: Wenn wir die Arbeit nicht schätzen, dann wird dies jemand anderes für uns erledigen! Das lindert den Druck auf die Entwickler nicht.
In den vergangenen 10 Jahren war ich an hunderten Refinement-Sessions beteiligt. Ich nahm auch an unzähligen Sprint Plannings und Workshops teil. In diesen Terminen wurden sicherlich hunderte, vielleicht sogar tausende Stories geschätzt. Dabei haben wir viele Fehler gemacht. Wenn ich auf diese Fehler zurückblicke, wird mir eines klar: Sie alle haben eine gemeinsame Ursache. Es lag nicht an der technischen Expertise der Entwickler. Auch war es nicht die Schuld des Product Owners, der die Stories vielleicht nicht gut genug erklärte. Der wahre Grund lag in der menschlichen Psychologie.
Die Ursache liegt im Verhalten der Menschen in Gruppen.
Wenn du aus meinen Fehlern lernen willst, dann lies weiter:
Planning Poker Schritt für Schritt erklärt
Planning Poker geht auf James Grenning zurück.
Es hilft Scrum Teams, Product-Backlog-Einträge zu verstehen und ein gemeinsames Verständnis über deren Größe zu erlangen. Das Vorbild ist eine Pokerrunde.
Hier die Spielregeln:
- Jeder Entwickler erhält die gleichen Karten. Üblicherweise enthalten die Karten die Zahlen der Fibonacci-Reihe.
- Der Product Owner stellt den zu schätzenden Eintrag aus dem Product Backlog vor.
- Jeder Entwickler schätzt den Eintrag, indem er ihm eine Größe zuordnet. Die Zuordnung erfolgt, indem er verdeckt eine Karte wählt. Seine Wahl bleibt so lange verdeckt, bis alle geschätzt haben. Danach zeigen alle Entwickler gleichzeitig ihre Wahl. Gibt es keine Übereinstimmung in der Größe für den Product-Backlog-Eintrag, diskutieren die Entwickler mit den höchsten und niedrigsten Schätzungen ihre Wahlen. Danach wird dieser Eintrag erneut von allen geschätzt (Schritt 3). Dieser Schritt wird so lange wiederholt, bis eine Einigung erzielt wird. Diese Einigung spiegelt das gemeinsame Verständnis über den Product-Backlog-Eintrag wider.
So oder so ähnlich kennst du bestimmt auch Planning Poker. Klingt sehr einfach. Die Fehler verstecken sich in den Details, denen wir uns jetzt widmen.
Fehler 1: Keine Referenz-User-Story
Wie würdest du diese beiden Fragen beantworten?
- Ist Reykjavík mehr als 3 000 Kilometer von München entfernt?
- Wie hoch schätzt du die Distanz zwischen Reykjavík und München?
Wenn es dir wie den meisten Menschen geht, hat die in der ersten Frage genannte Zahl von 3 000 Kilometern (von mir willkürlich gewählt) deine Antwort auf die zweite Frage beeinflusst.
Ich stelle diese Fragen regelmäßig im „Professional Scrum Master“-Training , und dabei zeigt sich: Die Antworten auf die zweite Frage steigen in jedem Fall um viele hundert Kilometer, wenn ich eine größere Zahl in der ersten Frage verwende. Dieser einfache Test veranschaulicht ein weitverbreitetes Phänomen, den Ankereffekt. Der Ankereffekt führt dazu, dass unser Gehirn der ersten Information, die wir erhalten, ein unverhältnismäßig hohes Gewicht beimisst.
Was passiert, wenn ich nur die zweite Frage stelle?
Dann beobachte ich häufig, dass die Augen der Teilnehmer verlegen, nach rechts oben blicken und sie dann nach einigen Sekunden zögerlich sagen: „Ich habe keine Ahnung, ich müsste jetzt raten.“ Wenn ich sie dann bitte zu raten, kommen die unterschiedlichsten Antworten. Von 500 Kilometern bis hin zu 5 000 Kilometern habe ich bereits alles gehört. (Davor bin auch ich nicht gefeit. Ich wurde kürzlich in einem „Training from the Back of the Room“-Training gebeten, eine Frage zu beantworten. Die Teilnehmer wollten von mir wissen, wie viele Saiten eine Gitarre hat. Meine Antwort: 10! Danach haben alle gelacht. Zu meiner Verteidigung: Ich habe als Kind nur Blockflöte gelernt.)
Was können wir über das Schätzen von Größen aus diesen beiden Versuchen lernen?
- Ankern kann unser Gehirn verleiten, eine vermeintliche Abkürzung zu nehmen, indem es sich an der letzten Information orientiert, um anstrengendes Nachdenken zu ersparen.
- Ankern kann uns aber auch dabei unterstützen, von wildem Raten zu einer fundierten Vermutung zu gelangen.
Welche Auswirkungen haben diese Erkenntnisse nun auf das Schätzen von User Stories?
Ich werde es erklären:
Um zu erreichen, dass die Schätzungen so realistisch wie möglich sind, müssen wir einen guten Anker finden. Nach meiner Erfahrung ist ein guter Anker eine abgeschlossene User Story. Sie sollte im letzten Sprint vom Scrum Team vollständig umgesetzt worden sein. An ihr sollten so viele Mitglieder wie möglich mitgearbeitet haben.
Verwenden wir keine Referenz-Story, dann kann es dazu führen, dass die Entwickler nur wild drauflos raten.
Dies ist jedoch nicht der einzige Fehler:
Fehler 2: Schätzen geschieht sichtbar
Ein Mythos: Je mehr Menschen an einer Entscheidung beteiligt sind, desto besser ist die Entscheidung.
Erstmal klingt diese Aussage doch plausibel, oder? Mehr Menschen bedeutet mehr Sichtweisen und mehr Sichtweisen bedeuten, dass weniger Unbekanntes im Verborgenen bleibt.
Eigentlich eine stimmige Rechnung.
Leider wird dieser potenzielle Vorteil durch die Dynamik von Scrum Teams häufig zunichtegemacht.
Teams neigen von Natur aus zum Herdendenken. Das bedeutet: Die Mitglieder bestätigen sich gegenseitig in ihren Überzeugungen. Dieser Effekt verstärkt sich zunehmend, je mehr sich das Team einem Konsens nähert. Denn sobald wir das Gefühl haben, dass das Team bereits einen Konsens gefunden hat, fällt es uns schwerer, einen Einwand zu äußern. Warum ist das so? Ganz einfach: Wir wollen nicht als „Neinsager“ oder „Querulant“ in der Gruppe wahrgenommen werden, sondern als „Teamspieler“.
Du stimmst mir nicht zu? Du bist jemand, der immer und überall seine Meinung sagt?
Dann lass mich dir eine Frage stellen:
Denke bitte an die letzte miserable Theateraufführung, die schlechte Rede des Vorstands oder die unverdiente Auszeichnung eines Kollegen. Hast du nicht auch am Ende wie alle anderen geklatscht?
Du konntest einfach nicht anders. Der Wunsch, sich in die Gruppe einzufügen, stammt aus unserer Urvergangenheit. Das Überleben innerhalb des Stammes war schwierig, aber das Überleben außerhalb des Stammes war unmöglich.
Wie hilft dir die Erkenntnis über Herdendenken beim Schätzen von User Stories?
Du solltest unter allen Umständen dafür sorgen, dass die Mitglieder des Teams verdeckt ihre Wahl treffen und alle gemeinsam umdrehen. Der Product Owner stellt die Story vor. Bei dieser Vorstellung sollte es keine Diskussion über den Aufwand oder den Inhalt unter den Entwicklern geben. Diskussionen können unbeabsichtigt zu einem Konsens unter einigen Entwicklern führen. Andere Teammitglieder könnten dann zögern, damit sie nicht als „Neinsager“ angesehen werden. Wenn es um das Schätzen geht, schließen sie sich möglicherweise der Gruppenmeinung an, um nicht aufzufallen.
Deshalb sollte das Schätzen immer verdeckt passieren.
Es kann aber noch zu weiteren Fehlern kommen:
Fehler 3: Der Durchschnitt bildet die Schätzung
Würdest du einen Fluss durchqueren, der im Schnitt einen Meter tief ist?
Wenn du nicht schwimmen kannst, würde ich es dir nicht raten. Der Durchschnitt von einem Meter bedeutet nicht, dass es nicht auch Stellen geben kann, die zwei Meter tief sind. Bei der Überquerung des Flusses ist also Vorsicht geboten. Dieses Beispiel zeigt eine wichtige Erkenntnis. Es verdeutlicht, dass die Verwendung von Durchschnittswerten zu gefährlichen Fehleinschätzungen führen kann. Dies ist besonders der Fall, wenn die Varianz der Daten ignoriert wird.
Dies gilt es auch bei der Schätzung von User Stories zu beachten.
Ich musste häufig beobachten, wie Karten aufgedeckt wurden. Nachdem die Karten offenlagen, nahm der Entwickler oft einfach den Durchschnitt. Dies geschah ohne jede weitere Diskussion. Leider schützt dich aber auch eine weitere Diskussion über die Story nicht vor Fehlern. Bei der Diskussion kann es schnell zum Herdendenken kommen.
Wie kannst du dein Team davor bewahren?
Anstatt nur wild zu diskutieren, wähle einen strukturierten Ansatz. Ziel sollte es sein, dass jeder Entwickler für sich die Grenzfälle durchdenkt.
Hierzu möchte ich dir zwei bewährte Methoden vorstellen.
Beginnen wir mit dem schlimmsten Fall.
Pre-Mortem: Hilft, die größte Schätzung zu verstehen
Beginnen wir mit der Analyse der möglichen Probleme. Wir wollen verstehen, warum ein Entwickler die User Story als besonders umfangreich einschätzt.
Hier wählen wir eine Methode, die du aus Krimis kennst. Nachdem die Leiche gefunden wurde, rückt die Mordkommission an und die Leiche wird obduziert, um die Todesursache festzustellen. Diese Methode hat sich auch im Projektmanagement etabliert. Dort heißt sie Post-Mortem. Nach einem missglückten Projekt kommt das Projektteam zusammen und untersucht, wie es dazu kam. Hierbei gibt es nur ein Problem: Das Projekt ist bereits tot, das Team kann nunmehr aus seinen Fehlern fürs nächste Mal lernen.
Warum also nicht die Obduktion vor dem Tod des Projekts durchführen?
Diese Frage hat sich auch der bekannte Psychologe Gary Klein gestellt und daraufhin die Methode des Pre-Mortem entwickelt.
Sie funktioniert wie folgt:
- Betrachte die User Story und nimm an, dass sie nach drei Sprints immer noch nicht abgeschlossen ist. Drei Sprints stehen hier für die größte Zahl, die beim Planning Poker gewählt wurde. Du kannst auch XXL nehmen, aber das ist aus meiner Sicht weniger greifbar.
- Stelle dir nun vor, dass du dich im darauf folgenden Sprint befindest. Wenn du auf die Arbeit an dieser User Story zurückblickst, liste fünf Gründe auf, warum die User Story nicht fertiggestellt werden konnte. Nenne nur Gründe, die im Einflussbereich von dir oder deinem Team liegen.
- Nun wiederhole diesen Schritt, aber diesmal nenne fünf Gründe, die außerhalb des Einflussbereichs deines Teams liegen.
Jeder Entwickler muss die Pre-Mortem-Analyse eigenständig durchführen, um Herdendenken zu vermeiden. Erst wenn alle Teammitglieder zehn Gründe gefunden haben, beginnt die Vorstellung im Team.
Pre-Mortem hilft den Entwicklern, gemeinsam die größte Schätzung zu verstehen.
Nun widmen wir uns dem besten Fall:
Backcasting: Hilft, die kleinste Schätzung zu verstehen
Jetzt wollen wir verstehen, warum diese User Story für einige Teammitglieder nur so wenig Arbeit erfordert.
Diese Methode geht auf Chip Heath und Dan Heath zurück und heißt Backcasting. Beim Backcasting nutzen wir eine Technik der Vorstellungskraft. Wir stellen uns vor, die betrachtete User Story war wirklich nur wenig Aufwand. Der Aufwand entspricht der kleinsten Größe, die beim Planning Poker gewählt wurde. Und wir fragen uns nun: „Wie ist das passiert?“
Hierbei sind die Schritte für das Backcasting ähnlich zum Pre-Mortem:
- Betrachte die User Story und nimm an, dass sie nach einem Sprint bereits abgeschlossen ist.
- Stelle dir nun vor, dass du dich im darauf folgenden Sprint befindest. Wenn du auf die Arbeit an dieser User Story zurückblickst, liste fünf Gründe auf, warum die User Story so schnell fertiggestellt werden konnte. Nenne nur Gründe, die im Einflussbereich von dir oder deinem Team liegen.
- Nun wiederhole diesen Schritt, aber diesmal nenne fünf Gründe, die außerhalb des Einflussbereichs deines Teams liegen.
Abermals muss jeder Entwickler das Backcasting eigenständig durchführen, um Herdendenken zu vermeiden. Erst wenn alle Teammitglieder zehn Gründe gefunden haben, beginnt die Vorstellung im Team.
Backcasting hilft den Entwicklern, gemeinsam die kleinste Schätzung zu verstehen.
Im Anschluss an die Pre-Mortem-Analyse und das Backcasting schätzen die Entwickler die User Story erneut. Wir befinden uns im vierten Schritt des Planning-Poker-Prozesses.
Pre-Mortem hilft, sich auf einen Regentag vorzubereiten, aber es regnet nicht ununterbrochen. Deshalb muss sich das Team auch vorstellen, wie es ist, wenn die Sonne scheint. Dabei hilft Backcasting. Wenn es beide Möglichkeiten auslotet, ohne in eine Diskussion zu verfallen, ist das Ergebnis meist eine genauere Schätzung!