Planning Poker und wortreiche Entwickler [geschlossen]

Mein Team besteht aus 4 Entwicklern; alle erfahren und kompetent. Einer von ihnen ist ein wortreicher, gut gemeinter Kerl, der darauf besteht, die technische Lösung für unsere Geschichten zu definieren, bevor wir unsere Schätzungen bei Planning Poker niederlegen. Er weigert sich zu schätzen, wenn er keine grobe Vorstellung von der vereinbarten technischen Lösung hat (was klingt vernünftig, oder?).

Das Problem ist, dass es ewig dauert, bis unsere Schätzungssitzungen abgeschlossen sind !! Wie gehen Sie Ihrer Erfahrung nach mit dieser Art von Persönlichkeit um, wenn Sie Planungspoker spielen?

Er scheint es zu mögen, wenn Dinge formal definiert werden, daher wäre ein Timer eine gute Idee, da bei der Planung von Poker festgelegt wird, dass die Zeit zum Sprechen festgelegt ist.

Er hat auch die falsche Vorstellung von der Schätzung, jeder schätzt gegen die Geschichte und nicht gegen die Implementierung , weshalb man solche Abweichungen bekommt. Zum Beispiel können einige Leute ein Framework oder eine Standardlösung nicht kennen und anfangen, Dinge von Grund auf neu zu schreiben.

Ihr Teammitglied klingt nach einer Analystenpersönlichkeit. Analysten benötigen viele Informationen, um eine Entscheidung zu treffen. Die Timer-Idee ist am besten, aber sei dir bewusst, dass er alles, was er gibt, zum Teufel machen wird. Arbeiten Sie mit ihm zusammen, um zu erklären, dass es sich nur um eine frühe Schätzung handelt, die auf dem Problem und NICHT auf der Lösung basiert. Wenn er Fragen stellen möchte, bitten Sie ihn, das Problem und nicht die Lösung beizubehalten. Möglicherweise müssen Sie ihn für eine Weile abschneiden oder ärgern, wenn er immer wieder nach Lösungen sucht.

Stellen Sie sicher, dass Sie andere im Team nach denselben Regeln halten, damit er sich nicht herausgehoben fühlt. Analysten sind eine gängige Persönlichkeit in der Programmierung, so dass Sie möglicherweise auf andere wie ihn treffen.

Es hört sich so an, als ob Ihr Kollege den Unterschied zwischen Schätzung und Engagement nicht versteht oder ihm während des Trainings nicht mitgeteilt wurde. Und da Sie versucht haben, das Problem mit seiner Persönlichkeit in Verbindung zu bringen, ist es möglich, dass Ihr gesamtes Team es noch nicht versteht. (Aber keine Sorge! Die meisten unserer Branchen verstehen das nicht. Agil ist schwer!)

Wenn wir sagen, dass die Größe einer Geschichte X Punkte beträgt, meinen wir tatsächlich eine Wahrscheinlichkeitsverteilung. Wenn unsere Schätzungen korrekt sind, sollte die Geschichte 50% der Zeit länger dauern (und die anderen 50% weniger Zeit). Wenn Ihr Kollege der Ansicht ist, dass er nach Ablauf von X Zeiteinheiten aufgefordert wird, die Geschichte zu demonstrieren, ändert sich sonst seine Herangehensweise an die Schätzung.

Das Planen von Poker führt zu einem weiteren Fehler: Anstatt zu versuchen, X festzuhalten, ordnen wir es einer diskreten Skala zu, wobei die Fibonacci-Skala (1, 2, 3, 5, 8 usw.) am beliebtesten ist. Es heißt, dass die Größe nicht so groß ist wie die Größe. Wenn wir sagen, dass die Story-Größe 3 Punkte beträgt, sagen wir wirklich: "Es ist X plus-minus eine gewisse Varianz und X ist näher an 3 als an 2 oder 5."

Ihr Team könnte davon profitieren, zu verstehen, wie ungenau diese Übung ist und wie sich die Schätzung vom Engagement unterscheidet. Wenn Sie diese Konzepte gründlich studieren möchten / müssen, finden Sie in diesem Buch diese Informationen .

Ich kann sehen, woher Ihr Teammitglied kommt, aber er hat das Konzept von Agile and Planning Poker offensichtlich nicht vollständig verstanden. Sie sollten zunächst sicherstellen, dass jeder die Konzepte und die Gründe dafür versteht, und dann sollten sie es selbst richtig machen.

Für die Teams, mit denen ich zusammenarbeite, stelle ich zu Beginn jeder Planungssitzung einen 3-Minuten-Sand-Timer auf den Tisch. Ich lasse das gesamte Team wissen, dass jeder im Team, wenn er das Gefühl hat, dass das Gespräch zu einem tiefen oder irrelevanten Punkt wird oder auf andere Weise über das hinausgeht, was er für erforderlich hält, um die Geschichte in Story-Punkten einzuschätzen kann den Timer umdrehen. Sobald der Sand ausgeht, schätzt das Team sofort.

Diese Methode ermöglicht es jedem Einzelnen im Team, die Konversation einzuschränken, wenn er der Meinung ist, dass die Konversation nicht mehr nützlich ist, um die diskutierte Geschichte abzuschätzen. Gleichzeitig wird die Konversation nicht sofort unterbrochen, sondern es wird jedem visuell angezeigt, dass die Konversation in den nächsten Minuten abgeschlossen sein muss, da wir dann abstimmen werden.

Ein weiteres Tool, mit dem ich die Planungssitzungen fokussieren kann, besteht darin, sicherzustellen, dass alle Mitglieder des Teams die Storys mindestens ein paar Tage vor der Planung oben im Backlog überprüft haben. Die Idee ist, dass Sie, wenn Sie unmittelbar nach dem Lesen der Geschichten eine Liste mit Fragen haben, den Produktbesitzer einige Tage zuvor über die möglichen Fragen informieren können, damit er die Geschichte oder die Akzeptanzkriterien klären kann, um die spätere Diskussion hoffentlich einzuschränken. Dies ermöglicht es den Leuten auch, über das mögliche Design der Geschichte nachzudenken, bevor sie in Planung sind (und versuchen, während der Planung zu entwerfen).