Wir empfehlen zum Thema Ressourcen

1 Stunde

08.05.2025

Websession: Mehr Überblick, weniger Engpässe: Ressourcen mit KI & BI optimal steuern - powered by Can Do

Mit KI & BI Engpässe vermeiden, Ressourcen effizient planen und fundierte Entscheidungen treffen – Can Do zeigt, wie das gelingt. Erfahren Sie live, wie Unternehmen Risiken minimieren und ihre Projektlandschaft transparenter steuern können. Mehr Infos

Schritt 1: Bereiten Sie den Planning-Poker-Workshop vor!

Überprüfen Sie, ob die User Storys in der aktuellen Fassung und vollständig vorliegen. Stellen Sie sicher, dass alle zu behandelnden User Storys auf Moderationskarten gedruckt / geschrieben werden.

Achten Sie darauf, dass alle nachfolgenden Teamrollen besetzt sind:

• Product Owner: Er vertritt die Seite des Auftraggebers, priorisiert User Storys und steht den Schätzern zur Verfügung, um User Storys detailliert zu erläutern. Der Product Owner gibt keine Schätzungen ab.
• Scrum Master: Üblicherweise organisiert er das Planning Poker, achtet auf die Einhaltung der Spielregeln und dokumentiert die Ergebnisse.
• Entwickler: Sie realisieren später die User Storys. Durch ihr Fachwissen und ihre Erfahrungen aus anderen Projekten liefern sie den essenziellen Beitrag für das Planning Poker. Die Entwickler liefern die Schätzungen, ggf. geben auch Spezialisten Schätzungen ab (s.u.).
• Spezialisten (z.B. Analysten): Ist Ihnen vorab bekannt, dass bei den Entwicklern fachliche Wissenslücken vorhanden sind, können Sie die Runde durch Experten für diese Themen ergänzen. Diese unterstützen das Team indem sie fachliche Rückfragen beantworten und beteiligten sich bei denjenigen User Storys an der Schätzung, für die sie Experten sind.

Benennen Sie bei der Einladung zum Planning Poker das zu schätzende Vorhaben (Ihr Projekt).

Ergänzen Sie bei der erstmaligen Anwendung Hinweise zum Thema Planning Poker. Planen Sie bei einem mit Planning Poker unerfahrenen Team mehr Zeit ein, um Vorbereitungsrunden durchzuführen, bei denen die Teilnehmer die Methode lernen und einüben.

Schritt 2: Workshop-Auftakt

Der Product Owner präsentiert die Produkt/Projekt-Vision und stellt die thematischen Schwerpunkte des nächsten, zu schätzenden Sprints vor. Der Scrum Master stellt neue Teammitglieder und hinzugezogene Experten vor. Ferner erläutert er, dass mit Hilfe von ein bis zwei Einstimmungsrunden mit dafür geeigneten User Storys die "Kalibrierung", sprich das gruppenweite Verständnis zu Kartenwerten, erreicht wird.

Schritt 2: Stellen Sie die Methode Planning Poker und die Kartenwerte vor!

Beschreiben Sie, je nach Vorkenntnissen der Teilnehmer, das Prinzip und die Funktionsweise von Planning Poker. Erklären Sie in jedem Fall die Aufgaben der einzelnen Rollen (s.o.) und erläutern Sie die Kartenwerte:

• Die Sonderkarte "0" bedeutet, dass die Aufgabe nach Meinung des Teilnehmers bereits erledigt wurde.
• Die Sonderkarte "?" sollte ein Teilnehmer dann wählen, wenn er während des Schätzens feststellt, dass er die Aufgabe nicht verstanden hat oder er weitere Informationen benötigt, um eine Schätzung abgeben zu können.
• Die Sonderkarte mit dem Symbol "Kaffeetasse" zeigt auf, dass der Teilnehmer eine Pause beantragt.
• Zahlenkarten: Der Zahlenwert gibt an, wie hoch der Teilnehmer den Aufwand zur Realisierung der Aufgabe hält im Vergleich zu einer Referenzaufgabe, die einen festgesetzten Zahlenwert erhält (z.B. 5).

Wenn die Teilnehmer noch keine Erfahrung mit Planning Poker haben, sollten Sie zwei bis drei Vorbereitungsrunden durchführen, in denen Sie die Schritte 3 bis 6 mit ausführlichen Erläuterungen und mehr Zeit für die Schätzungen durchführen. Evtl. können Sie die so erzielten Schätzwerte bereits verwenden, andernfalls legen Sie die User Storys wieder in den zu schätzenden Pool zurück.

Schritt 3: Präsentieren der User Story

Der Product Owner wählt eine User Story für die nächste Schätzrunde aus und stellt sie vor. Für die ersten beiden Schätzrunden sollte er User Storys aussuchen, die sich gut für die "Kalibrierung" eignen (s.o.).

Schritt 4: Klären Sie inhaltliche Fragen zur User Story

Der Moderator (z.B. der Scrum Master) frägt die Teilnehmer, ob alle die User Story vollständig verstanden haben. Bei Bedarf moderiert er die Klärung der Fragen. Wenn es zu keiner Klärung kommt, wird die User Story auf den nächsten Workshop vertagt. Der Product Owner muss die User Story bis dahin mit den entsprechenden Anforderungen verfeinern, damit er sie erneut einbringen kann.

Schritt 5: Die verdeckte Schätzung

Der Moderator fordert die Teilnehmer auf, die Schätzung vorzunehmen. Jeder Teilnehmer schätzt für sich den Aufwand für die betrachtete User Story, nimmt die Karte mit dem entsprechenden Zahlenwert (oder eine Sonderkarte) aus seinem Kartendeck und legt diese verdeckt vor sich ab. Der Moderator bestimmt, wie viel Zeit hierfür zur Verfügung steht, dies hängt insbesondere davon ab, wie die Entwickler mit der Methode vertraut sind.

Schritt 6: Begutachten Sie die Ergebnisse gemeinsam

Haben alle Teilnehmer den vorangegangenen Schritt ausgeführt, decken sie die Karten auf Kommando des Moderators auf. Begutachten Sie nun die Ergebnisse gemeinsam. Falls ein Teilnehmer eine der drei Sonderkarten "0", "?" oder "Kaffeetasse", gelegt hat, führen Sie die entsprechenden Schritte durch:

• "0": Überprüfen Sie, ob die User Story bereits erledigt wurde. Ist dies tatsächlich der Fall, vermerken Sie dies auf der Moderationskarte der User Story (Moderationskarte, evtl. auch bereits in der User Story selbst) und legen Sie die Karte für die anschließende Dokumentation zur Seite. Eine erneute Schätzung ist in diesem Fall nicht erforderlich. Falls die User Story noch nicht umgesetzt wurde, führen Sie die Schätzung nochmals durch.
• "?": Klären Sie die Rückfrage und führen Sie die Schätzung erneut durch.
• "Kaffeetasse": Klären Sie den allgemeinen Bedarf einer Pause. Führen Sie die Pause sofort durch, oder einigen Sie sich auf eine entsprechende Planung. Schätzen Sie anschließend die User Story erneut.

Besteht das Schätzergebnis ausschließlich aus Zahlenwerten, analysieren Sie die Häufigkeitsverteilung der Schätzwerte und gehen Sie dann wie folgt vor:

• Bestehen offensichtlich große Abweichungen zwischen den Schätzungen (z.B.: vier Personen geben einmal 2, zweimal 3 und einmal 8 Punkte als Schätzwert ab), erklärt die Person mit der höchsten und die Person mit der niedrigsten Karte den Grund für die jeweilige Entscheidung. Danach wird die gleiche User Story erneut geschätzt (beginnen Sie erneut bei Schritt 4).
• Handelt es sich um ähnliche Ergebnisse (z.B.: vier Personen geben zweimal 2 und zweimal 3 Punkte als Schätzwert ab, lassen Sie in höchstens zwei bis drei Minuten Diskussion die Gruppe zu einem Konsenswert finden und schreiben Sie diesen auf die User-Story-Karte.

Kommt es bei einer User Story mehrfach zu starken Abweichungen, dokumentieren Sie den Sachverhalt im Protokoll. Anschließend empfiehlt es sich, die Mehrheitsentscheidung zu akzeptieren und auf der User-Story-Karte zu dokumentieren. Es steht Ihnen ebenfalls frei, die Schätzung der betroffenen User Story ein weiteres Mal durchzuführen.

Uneinigkeit bei der Vergabe der Story Points pro User Story ist ein klares Indiz für Unsicherheiten bezüglich der zugrunde liegenden Aufgabe. Kann diese durch weitere Informationen zur Aufgabe nicht aufgelöst werden, fließt der Hinweis zum mangelnden Konsens in die Dokumentation der User Story mit ein. Schätzen Sie die User Story im vorangeschrittenen Projekt neu (sofern verschiebbar) oder übergeben Sie die Unsicherheit bezüglich der Aufgabe an Ihr Risikomanagement.

Schritt 7: Übergeben Sie die Ergebnisse an die Schnittstellen

• Überführen Sie die Ergebnisse (User Storys inklusive Konsens-Schätzungen) in das Product Backlog.
• Übersetzen Sie Bewertungsergebnisse in die Ressourcen- und Einsatzplanung und / oder Ihr Risikomanagement.