Scrum-Grundlagen: Agile Softwareentwicklung

So funktioniert Planning Poker

Testen Sie unsere 1983 Kurse

10 Tage kostenlos!

Jetzt testen Alle Abonnements anzeigen
Die Analyse zeigt, was im Meeting nicht optimal gelaufen ist. Im Anschluss erfahren Sie, wie man spielerisch mehr Wissen auf den Tisch bringt und Aufwände besser abschätzen kann.
06:41

Transkript

In diesem Film wollen wir kurz betrachten, was in dem Planungsmeeting gerade passiert ist. Ich glaube, das Team hat schon das Gefühl, das es relativ ungünstig gelaufen ist. Es war eigentlich eher ein Arbeiten auf Zuruf zwischen Tür und Angel, nur dass jetzt keine Tür und keine Angel gerade im Bild waren. Der Product-Owner war ziemlich schlecht vorbereitet. Er hatte sich vorher keine Gedanken gemacht, was genau eigentlich entstehen soll. Und vor allem hat er vergessen, sein wichtigstes Werkzeug, das Product-Backlog ins Meeting mit hineinzubringen, geschweige denn es gut vorbereitet zu haben. Das Product-Backlog ist wirklich die Arbeitsgrundlage, mit dem das Team die Aufwände, und das, was entstehen soll, greifbar macht. Das Team auf der anderen Seite hat es versäumt, die Gelegenheit zu nutzen, um Rückfragen zu stellen. Sie hätten den Product-Owner am Tisch gehabt, und hätten Detailfragen klären können. Sie hätten Ihn festnageln können, um herauszufinden wie genau die Features implementiert werden sollen. Sie haben es nicht gemacht, sondern gesagt: Ja, klingt einfach, wir können dir mal was bauen. Klar, die können schon was bauen, aber die Wahrscheinlichkeit, dass es genau das ist, was der Product-Owner braucht, ist doch eher gering. Der Product-Owner hat dem Team Zeitvorgaben gemacht. Er hat dem Team noch schnell hintenrum noch ein paar Zusatzfeatures abdiskutiert, und das soll absolut nicht sein. Das Team soll alleine die Gruppe von Personen sein, die festlegt wie viel Arbeit im nächsten Sprint bewältigbar ist. War wirklich eine sehr ungünstige Sache, die der Product-Owner da gemacht hat. Das Team selber hat nicht alles Wissen genutzt, das zur Verfügung steht. Es hat nur eine Person, es hat nur Michael abgeschätzt. D.h., alle Informationen, die vielleicht Robert noch hatte, sind unter den Tisch gefallen. Diese Abschätzungssache ist eines der heikelsten in Scrum Teams. Ungünstige Effekte, die durch ungünstige Abschätzungen entstehen können, sind z.B.: Wenn nur ein Teammitglied abschätzt, heißt es, dass möglicherweise nicht alles Wissen, das im Team vorhanden ist, auf dem Tisch ist. Nur wenn alles Wissen beieinander ist, kann man wirklich einordnen, wie groß oder wie überschaubar ist die Aufgabe, die zu tun ist. Bei Abschätzungen neigt man oft dazu, in absoluten Werten zu schätzen, anstatt vielleicht verschiedene Funktionalitäten zu vergleichen. Man könnte den Vergleich ziehen, dass es relativ schwer ist, zu schätzen, wie schnell ein Pferd rennen kann, und wie schnell ein Esel rennen kann. Sind es jetzt 40 Kilometer in der Stunde für ein Pferd und  vielleicht 37 für einen Esel? Schwer zu sagen. Aber es ist relativ einfach zu vergleichen: Ist ein Pferd schneller, oder ist ein Esel schneller? Das Pferd ist höchstwahrscheinlich schneller. Das fällt viel leichter. Und genau so sollte man in der Regel bei Software-Projekten tun. Vergleichen Sie die Umfänge von verschiedenen Funktionalitäten miteinander, anstatt in absoluten Werten zu schätzen. Bei Abschätzungen spricht man oft von sogenannten Ankern, die gesetzt werden. Sobald für ein Feature mal die Größenordnung "Das dauert 40 Stunden." fällt, dann dreht es sich auch nur noch um diese 40 Stunden, vielleicht um 42 oder um 38. Aber es wird in der Regel niemand mehr auf die Idee kommen zu sagen: "Ich glaube, das dauert 150 Stunden." Wenn mal so ein Anker gesetzt ist, ist es schwer, eine wirklich objektive Abschätzung noch hinzukriegen. Je nachdem, wie Ihr Team in der Vergangenheit Erfahrungen machen konnte, kann es entweder sein, dass sich die Teammitglieder gegenseitig überschätzen oder gegenseitig unterschätzen: "Ich mach es Dir schneller." "Ich mach es Dir noch schneller." Und die anderen Teammitglieder sagen vielleicht: Naja, das dauert nicht 50 sondern 60 oder 80 oder 100 Stunden. Und das tun sie, weil sie alle nacheinander ihre Werte auf den Tisch legen. Es wäre günstiger, wenn das alles gleichzeitig passieren würde, damit sie sich nicht gegenseitig beeinflussen können. Dafür gibt es eine sehr nette Abschätzungstechnik. Das nennt sich "Planning Poker". Und es ist tatsächlich wie Poker, denn man verwendet Karten. Jedes Teammitglied hat einen Satz von Karten mit Zahlen darauf. Das sind oft Fibonacci-Zahlen. Ich habe hier mal welche dabei; das sind dieselben wie auf dem Foto. Und es läuft so ab: Der Product- Owner stellt ein Feature vor, die Teammitglieder überlegen in abstrakten Storypoints, wie aufwendig, wie umfangreich diese Funktionalität ist. Überlegen sich eine Karte, legen die verdeckt auf den Tisch und decken die gleichzeitig auf, alle gleichzeitig. Damit ist schon mal ausgeschlossen, dass Sie sich gegenseitig hochsteigern oder unterbieten, sondern alle Fakten sind gleichzeitig auf dem Tisch. Meistens klaffen die Werte dann auseinander, von einer 3 über etliche Zahlen, die im Mittelbereich liegen, bis zu einer 25 bspw. Planning Poker gibt die Regel vor, dass die kleinste Zahl und die größte Zahl sich erklären müssen. D.h., das Teammitglied mit der großen Zahl erklärt: "Ja, wir müssen das aufwendiger testen. Das können wir bei uns nicht nachstellen, das müssen wir direkt beim Kunden tun. Deswegen habe ich das so hoch eingeschätzt." Die anderen Teammitglieder ziehen die Augenbrauen hoch und denken sich: "Aha, habe ich gar nicht daran gedacht." Auf der anderen Seite: Das Teammitglied mit der niedrigen Zahl sagt: "Wir hatten im letzten Track was ganz Ähnliches gemacht, wir müssen es nicht neu machen. 70 Prozent davon können wir wiederverwerten." Diese Info ist wiederum für die anderen Teammitglieder neu. D.h., nur durch die Tatsache, dass man so ein einfaches Instrument wie Planning Poker benutzt, stellt man sicher, dass Informationen zusammengetragen werden; dass alle abschätzen und dass alles Wissen auf den Tisch kommt. Und mit diesen Prinzipien wird es jetzt auch unser Team in unserem Projekt noch mal probieren. Ich selber werde in diesem neuen Versuch wieder in die Rolle des Product-Owners schlüpfen.

Scrum-Grundlagen: Agile Softwareentwicklung

Machen Sie sich mit der Softwareentwicklung mit Scrum vertraut und sehen Sie, wie Sie komplexe Projekte agiler, qualitativ besser, kundenorientierter und motivierter meistern.

3 Std. 34 min (49 Videos)
Derzeit sind keine Feedbacks vorhanden...
 

Dieser Online-Kurs ist als Download und als Streaming-Video verfügbar. Die gute Nachricht: Sie müssen sich nicht entscheiden - sobald Sie das Training erwerben, erhalten Sie Zugang zu beiden Optionen!

Der Download ermöglicht Ihnen die Offline-Nutzung des Trainings und bietet die Vorteile einer benutzerfreundlichen Abspielumgebung. Wenn Sie an verschiedenen Computern arbeiten, oder nicht den ganzen Kurs auf einmal herunterladen möchten, loggen Sie sich auf dieser Seite ein, um alle Videos des Trainings als Streaming-Video anzusehen.

Wir hoffen, dass Sie viel Freude und Erfolg mit diesem Video-Training haben werden. Falls Sie irgendwelche Fragen haben, zögern Sie nicht uns zu kontaktieren!