Skip to main content

Erfahrungsbericht: Wie die White-Elephant-Technik die Schätzung und Priorisierung vereinfacht wird und damit das Sprint-Planning verkürzt

November 17, 2023

Nach einem Training interessiert mich nur eine Frage:

Wie konnten die Teilnehmer die Inhalte des Trainings anwenden, um ihre Arbeit erfolgreicher zu erledigen?

Deshalb führe ich nach jedem Training persönliche Gespräche oder Umfragen durch.

Einerseits stelle ich diese Frage, da ich mehr über die alltäglichen Herausforderungen der Teilnehmer erfahren möchte und wissen will, wie ihnen die Inhalte des Trainings dabei helfen. Es ist ein großer Unterschied, ob die Teilnehmer das Training nur mit neuem Wissen verlassen, oder das Gelernte auch tatsächlich in ihrem Arbeitsalltag einsetzen. Andererseits ist der Beruf des Scrum Masters oder Product Owners für viele Unternehmen noch Neuland. Die Rollen, Erfolgskriterien und Karrierepfade sind oft noch unklar. Deshalb interessiere ich mich dafür, wie Scrum Anwender ihren Erfolg messen.

Heute lade ich dich ein, mit mir hinter die Kulissen zu schauen: Gemeinsam werden wir ein Interview auswerten und Einsichten für die Arbeit mit Scrum Teams ableiten.

Professional Scrum Master Training Simon Flossmann

Erfahrungsbericht von Stephanie nach dem „Professional Scrum Facilitation Skills“-Training

Ich habe den Namen geändert und die Antworten für eine bessere Lesbarkeit geringfügig aufbereitet.

Woran erkennst du, dass du als Scrum Masterin Erfolg hast?

Mir macht es sehr viel Spaß, produktiv im Team zu arbeiten und erfolgreich Themen voranzutreiben. Ich erkenne, dass ich als Scrum Masterin erfolgreich bin, wenn das Team motiviert dabei ist und wir wirklich gemeinsam ein Ziel verfolgen.

Nun möchte ich mehr über deinen Alltag als Scrum Masterin erfahren: Bitte wähle eine typische Situation, in der du das Scrum Team durch Moderation unterstützt hast.

Im Planning tat sich das Team mit dem Schätzen schwer und auch gemeinsam mit dem PO war die Priorisierung immer schwierig. Es gab immer wieder Meetings, in denen der PO und das DevTeam gemeinsam die nächsten Aufgaben besprachen und planten (vielleicht nicht Scrum in Reinform, aber so wird auf Wunsch des Kunden gearbeitet). Hier hat der PO immer seine Themen platziert und das DevTeam hatte Schwierigkeiten, offen zu kommunizieren, was sie realistisch in welcher Zeit schaffen können. Wenn Dinge dann nicht umgesetzt wurden, war der PO unzufrieden. Mit neuen Priorisierungstechniken aus der PSFS-Schulung war es viel leichter für beide Parteien, ein Gefühl für die Wichtigkeit und auch die Größe der einzelnen Tasks zu erhalten und somit eine bessere Planung für den kommenden Sprint / das Backlog zu erreichen.

Was waren bisher die größten Probleme, auf die du bei der Moderation des Meetings gestoßen bist?

Eingefahrene Muster: Der PO gibt seine Wünsche vor, erwartet aber schon, dass die Dinge sowieso nicht in der Zeit umgesetzt werden können, die er sich wünscht. Durch Abwehrhaltung und Wortwahl des POs wurde diese Einstellung direkt deutlich. Das Team möchte gute Stimmung machen und lässt sich im Gespräch immer wieder vom PO zu Aussagen hinreißen, die möglichst kurzfristige Liefertermine für Features zusagen, die sie dann nicht halten können.

Was hast du vor unserem Training unternommen, um diese Probleme zu lösen?

Hier war es schwierig, den PO zu einem wirklich offenen und vertrauensvollen Austausch zu bewegen, um ein valides Ergebnis zu erreichen, mit dem er sicher planen kann, auch wenn das bedeutet, dass einige seiner Zieltermine nach hinten verschoben werden müssen. Ich habe versucht, Verständnis für beide Positionen aufzubauen und sie gegenseitig sichtbar zu machen. Das ist auch grundsätzlich gelungen. Trotzdem waren die Standpunkte beider Parteien immer gleich, auch wenn sie ihr Gegenüber grundsätzlich verstanden.

Nachdem du das Training besucht hast, wie gehst du jetzt mit diesen Problemen um?

[Die bisherigen Versuche] konnten das Problem nicht lösen. Mittels der White-Elephant-Technik konnten wir im Team erstmals alle Punkte mit dem PO priorisieren und parallel auch einmal die Größe der Themen auf einer anderen Wand sortieren. So hat der PO auch besser verstanden, wie groß einzelne Themen sind und wo er auf schnellere Lieferungen hoffen konnte, wenn er sich auf kleinere Features fokussierte.

Aus Stephanies Erfahrung können wir drei einfache Einsichten für unsere Arbeit ableiten.

Einsicht 1: Ein gemeinsames Verständnis von Wichtigkeit und Größe der Arbeit führt zu einer besseren Planung des Sprints

Diese Situation ist weitverbreitet:

„Im Planning tat sich das Team mit dem Schätzen schwer und auch gemeinsam mit dem PO war die Priorisierung immer schwierig.“

Aus eigener Erfahrung weiß ich, wenn die Arbeit regelmäßig erst im Sprint Planning geschätzt wird, dann erschwert dies, das Ziel des Sprint Plannings zügig zu erreichen. Selbst wenn du nicht in einem Scrum Team arbeitest, kennst du das.

Denke nur ans Kochen. Wenn du versuchst, das Gemüse zu waschen, zu schneiden und zu schälen, während du das Fleisch anbrätst, wirst du schnell feststellen, dass dieser Ansatz nicht nur anstrengend und erschöpfend ist, sondern auch zu verbrannten Gerichten führen kann. Damit es nicht zu verbranntem Fleisch und somit zu einem ungenießbaren Gericht kommt, bereiten Profi-Köche die Zutaten vor dem Kochen vor. Beim Kochen wird diese Aktivität „Mise en Place“ genannt. In Scrum nennen wir es Refinement. Der Scrum Guide beschreibt es folgendermaßen:

„Das Refinement des Product Backlogs ist der Vorgang, durch den Product-Backlog-Einträge in kleinere, präzisere Elemente zerlegt und weiter definiert werden. Dies ist eine kontinuierliche Aktivität, wodurch weitere Details wie Beschreibung, Reihenfolge und Größe ergänzt werden. Die Attribute variieren oft je nach Arbeitsumfeld.“

Damit im Sprint Planning nichts anbrennt, sollte die Schätzung des Aufwands der Einträge und die Festlegung ihrer Reihenfolge vor dem Sprint Planning passiert sein.

Stephanie ist mit dieser Situation nicht allein. Laut einer Umfrage im Zombie Scrum Survival Guide investieren 43 % der Scrum Teams im aktuellen Sprint keine Zeit in die Verfeinerung der Arbeit für kommende Sprints.

Das muss aber nicht so bleiben.

Einsicht 2: Es genügt nur eine Technik, um den Aufwand zu schätzen und die Themen zu priorisieren

„Mit neuen Prio-Techniken aus der PSFS-Schulung war es viel leichter für beide Parteien ein Gefühl für die Wichtigkeit und auch die Größe der einzelnen Tasks zu erhalten und somit eine bessere Planung für den kommenden Sprint / das Backlog zu erreichen.“

Die Prio-Technik, die sie anspricht, ist kein Geheimnis, allerdings noch wenig bekannt. Sie heißt „White-Elephant“ und beruht auf dem Prinzip des relativen Schätzens.

Hier die einzelnen Schritte:

Der Moderator startet einen 30-Sekunden-Timer, damit ist das erste Teammitglied an der Reihe.

  • Es wählt einen Product-Backlog-Eintrag aus und liest diesen laut vor.
  • Dann platziert es den Eintrag auf einer Skala dort, wo es glaubt, dass er im Kontext am besten passt. Die Skala reicht bei Aufwandschätzung von sehr klein bis sehr groß.
  • Nun begründet das Teammitglied, warum es die Karte dort platziert hat.
  • Dann ist das nächste Teammitglied an der Reihe, und der Prozess wird wiederholt, wobei der Moderator die Zeit neu startet.
  • Wenn alle Einträge auf der Skala platziert wurden, werden Anpassungen zur Reihenfolge vorgenommen.
  • Der Moderator gibt jedem Teammitglied der Reihe nach die Gelegenheit, einen Eintrag auf der Skala zu verschieben. Dafür hat das Teammitglied eine Minute Zeit.
  • Das Teammitglied nennt den Grund, warum es das Element verschoben hat, und das nächste Mitglied ist an der Reihe.
  • Dies geschieht so lange, bis alle Teammitglieder mit der Anordnung zufrieden sind.

Das Resultat dieser Methode für Stephanie:

„Mittels der White-Elephant-Technik konnten wir im Team erstmal alle Punkte mit dem PO priorisieren und parallel auch einmal die Größe der Themen auf einer anderen Wand sortieren.“

Das Geniale an dieser Technik?

Wie du lesen kannst, verwendete Stephanie sie nicht nur für die Schätzung des Aufwands der Arbeit, sondern auch zur Priorisierung der Einträge im Product Backlog. Das bedeutet, du kannst sie auch dazu verwenden, dass Product Owner und Stakeholder sich auf eine Reihenfolge des Product Backlogs einigen. Also eine Technik für zwei Anwendungsbereiche. Das macht diese Technik so genial.

Ach, da wir gerade dabei sind: Falls du dich bisher wenig mit Techniken zur Priorisierung beschäftigt hast, lege ich dir mein „Professional Scrum Facilitation Skills“-Training ans Herz. Das ist der Einstiegskurs zu Facilitation in Scrum Teams – speziell für alle, denen Stephanies Situation bekannt vorkommt.

Einsicht 3: Fokussierung auf kleinere Features führt zu einer schnellen Lieferung

Durch das Schätzen des Aufwands und der Priorisierung der Einträge entsteht ein gemeinsames Verständnis über die Arbeit. In Scrum nennen wir das Transparenz. Diese Transparenz ist die Grundlage von Scrum und der Wettbewerbsvorteil für Teams, die Scrum verwenden.

Was meine ich damit? Stephanie beschreibt es so:

„So hat der PO auch besser verstanden, wie groß einzelne Themen sind und wo er auf schnellere Lieferungen hoffen konnte, wenn er sich auf kleinere Features fokussiert.“

Warum ist der Fokus auf kleinere Features ein Wettbewerbsvorteil? Laut einer Umfrage im Zombie Scrum Survival Guide haben 39 % der Scrum Teams in der Regel kein Inkrement, das am Ende eines Sprints ausgeliefert werden kann.

Wenn das Team am Ende des Sprints liefert, dann ändert dies alles. Denn es ist doch so:

Schnelles Liefern bedeutet, Risiken zu minimieren!

Schnelle Lieferung ist die Grundlage für schnelles Lernen. Es bedeutet schnell zu erfahren, was funktioniert und was nicht. Das Team lernt schnell, was die Nutzer begeistert und was nicht. Und das Team erhält schnell Rückmeldungen darüber, was Stakeholder und Kunden zufriedenstellt und was nicht.

Fazit: Die Einsichten aus Stephanies Erfahrungen beschreiben, was Scrum im Kern ausmacht

Wenn du die White-Elephant-Technik zur Aufwandsschätzung und Priorisierung einsetzt, dann hilfst du jedem im Team, ein Gefühl für die Wichtigkeit und auch die Größe der einzelnen Aufgaben zu bekommen. Dies erleichtert die Planung des Sprints und die schnelle Lieferung von kleinen und wichtigen Einträgen. Dies hilft, Risiken zu minimieren, indem schnell gelernt werden kann, was funktioniert und was nicht.

Welche weiteren Einsichten entdeckst du in Stephanies Erfahrung? Schreibe sie unbedingt in die Kommentare.

 


What did you think about this post?