In dem Boot auf dem Roten Meer in Ägypten, kurz vor meinem allerersten Tauchgang, habe ich nicht mit meinem Tauchlehrer diskutiert, ob es die richtige Methode ist, auf die Innenseite der Taucherbrille zu spucken und meinen Speichel zu verteilen. Damit sie nicht beschlägt, während ich mich in 25 m Tiefe befinde und ich dann blind herumschwimme. Mein Tauchlehrer hat lediglich die kurze Anleitung gegeben, ist abgetaucht und … ich habs einfach gemacht.

Warum?

Er ist der Profi, also könnte es funktionieren. Der potentielle Diskussionspartner schwieg sowieso unter der Wasseroberfläche und Zeichensprache kann ich nicht so besonders gut. Die Zeit war knapp und ich beschloss, eben diese für den eigentlichen Tauchgang zu nutzen und ihn später zur Rechenschaft zu ziehen.

Zehn Jahre später befinde ich mich als Consultant von bor!sgloger auf einem anderen Schiff, in einer interessanten Projektsituation:

Wir haben 15 Minuten pro Scrum-Team, um mit ihnen ihr erstes Estimation Meeting durchzuführen. In Anbetracht der Zeit(-Not) bat ich das Team, mir zu vertrauen und in den nächsten 13 Minuten (2 Minuten waren schon aufgrund einer knappen, aber herzlichen Begrüßung und Vorstellung vergangen) zu schweigen und sich auf das Magic Estimation Meeting einzulassen.

“Ich verspreche, euch nach dem Meeting, in den kommenden Tagen zu JEDER Frage, JEDER Skepsis, JEDER Kritik bzgl. unserer Art und Weise zu schätzen, Rede und Antwort zu stehen. Wenn wir uns in den nächsten 12 Minuten einfach darauf einlassen und… einfach machen.

1 heißt User Story ist klein

2 User Story ist doppelt so groß

3 User Story ist wie 1 & 2

Fibonacci eben.

Die 13 sollte quasi euer Sprint-Limit darstellen und bei der 20 ist die User Story nicht “Sprint-Ready”, sprich zu groß und/oder komplex und/oder hat zu viele Features etc.

Euer Product Owner verteilt nun die User Stories, jeder schätzt die User Story, die er soeben erhalten hat und legt sie an die entsprechenden Storypoints.

Im Anschluss seht ihr euch die von euren Teamkollegen geschätzte User Stories an und schätzt ab, ob sie mit eurem Bauchgefühl d’accord gehen. Wenn ja – einfach liegen lassen und falls nein – einfach umlegen. Er darf es selbstverständlich zurücklegen. Nach dem dritten Mal wird die User Story aus dieser Runde herausgenommen und ist somit JETZT nicht mehr relevant.

Vielleicht wisst ihr von einem Teamkollegen, dass er mit dem Feature bzw. dem Thema einer User Story Erfahrung hat, und vertraut ihm bei seiner Schätzung.    

Das einzige Instrument, das ihr nun braucht, ist euer Bauch. Beruhigt ihn damit, dass ihr mich in den nächsten Tagen auf ein heißen Stuhl setzen dürft.

Wir haben nun noch 10 Minuten – also: Ab geht`s!

Grinsen, Stirnrunzeln und ein letztes “der ganz heiße Stuhl… hihi” – und es wird geschätzt.

Bei allen drei Teams, die ich in den nächsten 45 Minuten betreut habe, hat es tatsächlich ohne Probleme funktioniert. Aber warum? Warum wird das Schätzen immer wieder thematisiert und so gern stundenlang diskutiert?

Weil die Zeit dafür “da” ist.

Selbstverständlich habe ich in den nächsten Tagen viele Gespräche geführt und Erklärungen geliefert. Sehr oft habe ich dasselbe in verschiedenen Formulierungen und Beispielen beschrieben, den hervorragenden Blog meiner Kollegin Klessmann verteilt, und habe sogar mit Müll geschätzt. (Die Putzkolonne hatte aufgeräumt, es standen verschiedene volle, blaue Müllsäcke und diverse Pappkartons herum … Doing as a way of recycling. True story.) Wenn wir keine Zeit haben, uns mit etwas genauer zu beschäftigen, fällt es uns Menschen doch wesentlich einfacher zu vertrauen, intuitiv Entscheidungen zu fällen und unseren Bauch gewähren zu lassen.

Natürlich werde ich weiterhin Erklärungen und Fragen zu unseren Methoden liefern. Die erste Erkenntnis hinkt jedoch oft dem Vertrauen und dem Tun hinterher. Die kleinen Verbesserungen kommen dann ganz von allein:

  • Man bespricht selbstverständlich die User Stories lange vor dem Magic Estimation
  • Man verzichtet selbstverständlich auf Knoblauch lange vor seinem nächsten Tauchgang, denn die Antibeschlagsmethode ist simpel und funktioniert immer noch.
  • Stefanheintz

    Ich mache das Estimation Meeting auch nur noch auf dieser taffen Weise. Nein Spass bei Seite, ich bemerke auch jedesmal aufs neue, welcher gravierende zeitlichen Unterschied zwischen Planning Poker und Magic Estimation ist. Meine Lieblingsbeschäftigung während des Magic Estimation ist Fotos von dem Team zu machen, weil das einfach zum schreien aussieht wie jeder in Reihe auf dem Boden schaut. Das ähnelt dem Suchen nach dem 1 Euro-Stück. Die Fotos zeige ich dann dem Team in der Retro, was immer wieder zu einem Grinsen führt.

  • Pingback: Tauchen und Agilität()