Das Einzige was etwas schade ist:
Es gibt keine einzige Pokervariante, die auf dieser Spiel-Basis funktioniert

Die Null macht natürlich nur Sinn, wenn die Ziffern eine abstrakte Einheit wie Story Points darstellen. Null Aufwand für eine User Story in Zeit gibt es nicht, wohl aber in Sachen Komplexität.

Folgen wir dem Beispiel mit dem Kontaktformular, das den Story Point Wert 2 hat, könnte bspw. eine 0 Point Story sein: “Der User soll sich am System abmelden können.”Im minimalen Fall lässt sich diese Story in 3 Tasks runter brechen: Link zum Logout setzen, Session löschen, Redirect auf Startseite. Die Tasks kosten natürlich ein bisschen Zeit aber von der Komplexität zu einem Formular, mit Validierung und Datenverarbeitung fallen sie nicht wirklich ins Gewicht.

Mit Erfahrung des Teams lassen sich nach einigen Sprints auch tatsächliche Zeitaufwände für 0er Stories finden. Die 0er Story Point sind genauso berechtigt wie die 100er. Ist eine 0er Story so gering, dass sie fast keine darstellt, kann man überlegen, sie mit einer anderen geringen zusammenfassen.

Welche Artikel es noch geben wird, muss ich zum einen mit Nils abstimmen und zum anderen einmal recherchieren, zu was schon geschrieben wurde, damit es keine Doppelungen gibt. Was mich an der Thematik interessiert ist etwa der Workflow in agilen Projekten, auch in Hinsicht auf die eingesetzten Tools – aber lass Dich einfach überraschen. Ich freue mich jedenfalls, dass auch die nicht ganz so Hardcore-PHP-Themen gerne gelesen werden!

Zum Thema Teamgröße und Sinn des Verfahrens. Ein Scrum-Team besteht idealerweise aus 7 Personen, plus minus 2. Planning Poker ohne Scrum-Kontext kann man – so denke ich – getrost ab vier Leuten einsetzen. Das Wichtige dabei ist nicht zu vergessen, dass das Pokern ja nur eine Methode ist, um Konsens zu erzielen – den kann man ggf. auch zu zweit ohne Pokern erreichen.

Die Erfahrung des Teams spielt eine sehr große Rolle. Wenn das Team noch unerfahren ist, sollte auf jeden Fall ein erfahrender Scrum Master das Team begleiten. Er leitet das Team an und und hilft ihm dabei, sich zu verbessern – er ist der, wie ich letzten Artikel schrieb der “Kümmerer”. Die Stimme eines jeden Entwicklers zählt übrigens gleich. Kommt etwa ein neuer Entwickler hinzu ändert sich ja die gesamte Teamkonstellation und man muss einen temporären “Rückfall” in der Präzision der Schätzung und der Produktivität berücksichtigen.

Es gibt Techniken, um die sog. Velocity eines Teams zu messen und grafisch darzustellen. Daran kann man gut ablesen, wie sich das Team von Sprint zu Sprint verbessert. Diese Auswertungen sind bei Scrum übrigens nicht nur für das Management gedacht sondern für alle ständig einsehbar. Da sich das Verhältnis von Schätzung zu Implementierung und der allgemeinen Produktivität in der Regel steigert, ist dies für alle wichtig zu sehen und eine zusätzliche Motivation. Auch Fehleinschätzungen werden so sichtbar und lassen sich für den nächsten Sprint leichter korrigieren.

Pendelt sich das alles langsam auf einem Niveau ein, kann man von einem erfahrenden Team sprechen. Dann ist es auch besser möglich von angesetzten Story Points auf tatsächliche Zeitwerte abzuleiten.

Das kommt ganz drauf an, wie das Projekt aussieht – für jede Kleinigkeit macht es keinen Sinn. Auch wenn immer das gleiche gemacht wird (etwa eine Agentur, die standardisierte Produkte vertreibt) macht es auf Dauer keinen Sinn, weil klar ist, was anfällt.

Im Rahmen von Scrum findet eine Poker Session jeweils zu Beginn des Sprints / der Iteration statt. Sprich, alle zwei oder vier Wochen setzt man sich zusammen, schätzt, pokert und bestimmt dann, was in dem Sprint gemacht wird. Um jede User Story wird einzeln “gepokert”.

Wer Sorge hat, dass das ausufert, kann eine Eieruhr einsetzen und festlegen, dass die Schätzung einer User Story maximal X Minuten dauern darf. Bewegt man sich im Scrum Kontext, ist das ganze Planning Meeting 1, also das Meeting, in dem gepokert wird, ohne hin durch eine Time-Box begrenzt.

Aber auch bei kleineren Projekten kann es Sinn machen, auch ohne Scrum. Was mir persönlich an dem Verfahren gefällt, dass sowohl konservative Schätzer (wie beispielsweise ich) und die “jungen Wilden” in der Firma, die sehr progressiv schätzen, sich austauschen und _gemeinsam_ einen Konsens finden müssen. Jeder Beteiligte wird befragt und jede Stimme zählt gleich

Die Antwort auf Julians Frage, ob man mehrere Runden hintereinander spielt, würde mich auch interessieren.

Darüber hinaus interessiert mich, ab welcher Teamgröße das Planning Poker Sinn macht? Gibt es hier Erfahrungswerte?

Welche Rolle spielt die (Entwicklungs-)Erfahrung der beteiligten Personen? Wird die Schätzung eines Neulings im Team genauso gewichtet wie die eines “etablierten” Teammitglieds?