Estimojo

Planning Poker ist ein kleines Ritual mit einer einzigen wichtigen Regel: niemand sollte eine Zahl hören, bevor er seine eigene gewählt hat. Machen Sie es in einer Videokonferenz, und die Regel überlebt dank guter Manieren. Machen Sie es in einer Tabelle neben dem Ticket, und sie überlebt gar nicht, denn die Schätzung muss dann von Hand zurückkopiert werden, und wer sie kopiert, kann sie runden.

Estimojo lässt das Ritual auf dem Ticket selbst ablaufen, in Jira wie in monday.com. Hinter beiden steht eine einzige Schätzmaschine: die Tracker unterscheiden sich nur in einem Zugang mit rund einem Dutzend Methoden, sodass eine Regel über das Abstimmen einmal geschrieben wird und sich in beiden Werkzeugen gleich verhält.

Vor der Aufdeckung sieht niemand eine Zahl

Verdecktheit ist keine Frage einer Oberfläche, die etwas verbirgt, das man ihr geschickt hat. Vor der Aufdeckung trägt die Antwort, die der Bildschirm einer abstimmenden Person erhält, deren eigene Stimme und für alle anderen einen leeren Wert. Was sie sehr wohl trägt, ist, wer abgestimmt hat: der Raum sieht also, dass er auf eine Person wartet, ohne zu sehen, was die anderen gewählt haben. Das errechnete Ergebnis und die Kennzeichnung großer Uneinigkeit werden unter derselben Bedingung zurückgehalten. Die Aufdeckung ist ein Statuswechsel der Sitzung, und sie geschieht nur dann von selbst, wenn das Team es eingeschaltet hat, und zwar sobald die letzte teilnehmende Person gewählt hat.

Worauf der Raum sich einigte, und worauf nicht

Wenn die Stimmen aufgedeckt sind, ermittelt die Maschine die meistgewählten Werte und tut dann eines von drei Dingen. Gibt es einen einzigen meistgewählten Wert, wird er ausgewählt und als per Mehrheit entschieden vermerkt. Stehen mehrere Werte gleichauf, hängt das Weitere von einer Einstellung ab, die das Team wählt: eine Vorgabe nimmt den höchsten der gleichauf liegenden Werte und vermerkt ihn als per Stichentscheid bestimmt, eine andere übergibt den Gleichstand der koordinierenden Person und wählt gar nichts. Eine dritte Vorgabe ist auch im ersten Fall strenger: eine relative Mehrheit genügt nicht, und ein Wert, den nicht mehr als die Hälfte der Abstimmenden gewählt hat, gilt als überhaupt keine Entscheidung. Enthaltungen werden aus der Rechnung genommen, statt als niedrige Zahl zu zählen. Und ist die Streuung der Stimmen groß, gemessen als Standardabweichung über zwei, wird das Ergebnis gekennzeichnet, denn ein Raum, der im Mittel einig war, war es womöglich gar nicht.

Wo die Leiste sitzt, und wer starten darf

Die Leiste kann im Hauptteil des Tickets wohnen, in der Seitenspalte oder in beiden, und die Wahl gehört dem Projekt und nicht der einzelnen Person. Wer eine Sitzung starten darf, ist ebenfalls eine Einstellung: alle, oder nur die Person, der die Arbeit zugewiesen ist, oder nur wer das Ticket eröffnet hat. Das wirken wie kleine Entscheidungen, doch zusammen bestimmen sie, wessen Besprechung es ist: ein Team, in dem alle starten dürfen, hat eine andere Gewohnheit als eines, in dem nur die zuständige Person es tut, und das Werkzeug entscheidet nicht zwischen ihnen.

Ob die Schätzung etwas taugte

Schätzen lohnt sich nur, gemessen an dem, was danach geschah. Estimojo hält jede übernommene Schätzung fest und kann den Tracker fragen, wie lange ein Element gebraucht hat, um zwischen zwei Zuständen zu wechseln, die das Team benennt. Beides zusammengelegt ergibt ein Diagramm der Schätzung gegen die tatsächliche Dauer, über ein Fenster von bis zu vierundzwanzig Monaten. Das ist der Teil, den eine Retrospektive gebrauchen kann: nicht, wie schnell das Team abstimmt, sondern ob die Zahlen, auf die es sich einigte, am Ende etwas bedeutet haben.

Für wen es gedacht ist

Agile Teams, die in Jira oder monday.com schätzen und wollen, dass die Zahl am Ticket landet.

Besuchen Estimojo: estimojo.bomdisoft.com